Идеальная среда разработки / тестирования / QA для разработки - PullRequest
5 голосов
/ 26 мая 2010

Я работаю над перестройкой среды разработки, тестирования и контроля качества моей компании. У нас есть 10-15 программистов, которые участвуют в ряде проектов. В настоящее время все они разрабатываются локально на своих ПК и используют среду разработки для тестирования. В настоящее время у нас нет среды QA, поэтому развертывание часто является проблемой, потому что ошибки обычно обнаруживаются после того, как что-то запущено. Вот что я представляю:

  1. Отказ от всех привилегий локального администратора и разработка всех приложений на сервере dev
  2. Создание среды QA, идентичной нашим производственным системам. Это позволит им тестировать развертывания.
  3. Создайте новую тестовую среду, которая более закрыта, чем сервер разработки, чтобы можно было провести правильное тестирование.

Что ты думаешь? Каков наилучший способ создать такую ​​среду? Мы разрабатываем приложения ASP .NET с использованием MS Visual Studio 2008 (если это помогает).

Ответы [ 7 ]

4 голосов
/ 26 мая 2010

Как разработчик, я бы очень не хотел, если бы вы заблокировали мне права локального администратора.

Зачем всем заниматься разработкой на сервере разработки? Ваши сотрудники не все в офисе?

Единственное, что мне действительно нравится в ваших предложениях, это сервер QA, идентичный производственной среде. К сожалению.

Вы должны быть:

  • Управление кодом через контроль исходного кода
  • Иметь специального менеджера сборки, который отправляет сборки в QA. После одобрения QA / заключения бизнес-процесса / вставки вашего бизнес-процесса сюда, менеджер по сборке запускается в производство.
  • Надеюсь, у вас также есть тестовая среда для вашей базы данных. Администратор базы данных должен управлять продвижением изменений базы данных в производство. Разработчики создают в тестовой среде, которая представляет собой SQL Server / любой другой на другом сервере, который все используют.
  • Если вы используете продукты MS - рассмотрите возможность сделать свои проекты WDP (проекты веб-развертывания). MSBuild интегрируется с этим, и вы можете запустить сборку прямо, например, из задачи сборки TFS. Инкрементные сборки, ежедневные сборки, только ручные - это действительно хорошо, если вы правильно настроили его.
3 голосов
/ 26 мая 2010

Мне кажется, это кричит о Непрерывной интеграции . Здесь у вас будет вторая часть среды разработки, которая не является чьей-либо локальной машиной, но может использоваться для демонстрации того, что в данный момент делается, и обеспечения того, чтобы слияния кода не ломали вещи. Это отдельно от тестовой среды, которая используется QA, и должна быть другая среда, которая должна быть квазипроизводственной средой другого уровня, так что если есть исправления для публикации, это можно сделать отдельно, чем большие выпуски, которые могут потребовать больше времени чтобы QA выполнило достаточно регрессии, чтобы гарантировать, что новая функциональность не сломает много вещей.

0 голосов
/ 18 июля 2011

Помните - нет такой вещи, как "идеальная" общая среда разработки, которая могла бы применяться во всех случаях. Часто технические ограничения препятствуют полному принятию этих идей. Как подрядчик с известными годами, я обнаружил, что самая плохая система, с которой я работал, не имела прав локального администратора, каждая маленькая установка требовала обращения в службу технической поддержки, и они всегда ругали нас, разработчиков, за то, что они слишком много просили у них.

Лучший сценарий, который у меня был, заключается в следующем: если вы собираетесь удалить права локального администратора, предоставьте им мощную локальную виртуальную машину. У них должна быть DMZ в сети, чтобы они могли делать что угодно с виртуальной машиной. Если они что-то испортили, вы можете просто восстановить виртуальную машину из файла. В этом сценарии важно то, чтобы использовать хороший исходный репозиторий, такой как GIT, Team Foundation Server, SVN и т. Д. Таким образом, предполагается, что разработка должна осуществляться - без какой-либо зависимости от рабочих станций разработчика, помимо фактического ввода кода. .

Список этого и других советов:

Предоставить разработчикам полную свободу в их виртуальных машинах (доступ в Интернет, установка приложений и т. Д.)

Используйте хороший репозиторий управления исходным кодом, который каждый разработчик может разветвлять по своему усмотрению. Осуществляйте постоянные проверки (например, один раз в час) и используйте сервер сборки (непрерывная интеграция или «CI»), который проверяет наличие поврежденных сборок. Сервер CI должен отправить электронное письмо всем членам команды, когда сборка не работает.

Дайте каждому локальному компьютеру лучшие ресурсы, которые вы можете себе позволить. Я слышу этот аргумент, что 4 ГБ достаточно для Visual Studio. Нет ничего дальше от истины. Вы можете решить придерживаться этого, но, поверьте мне, - когда ваша машина разработчиков разматывает страницы на диск снова и снова, потому что каждая сборка занимает много памяти, вы теряете минуты каждый час - часы каждую неделю - из-за потери производительности, потому что медленных машин.

Постарайтесь не смотреть свысока на ваших разработчиков - они чувствуют запах этого за милю и обижаются на вас (хотите нести ответственность за недовольных разработчиков, удаляющих исходный код или представляющих ошибки?). Скорее всего, причина в том, что они «небрежные разработчики», потому что никто в компании не может управлять людьми. Лучшие команды возглавляют умные, открытые, образованные менеджеры проектов. Они получают то, что им нужно, когда им это нужно. Стоимость программного обеспечения НИЧЕГО по сравнению со стоимостью заработной платы разработчика - все же я все еще слышу о том или ином менеджере, отказывающемся от продукта, потому что он стоит очень дорого. В прошлый раз это был XML Spy - потому что «Блокнота хватит». Конечно, это будет так же, как хватит ног, а не машин, но я не хочу ходить везде, черт побери!

Идти против структуры - я на самом деле думаю, что удаление способности администратора у всех разработчиков - это хорошая вещь, ЕСЛИ вы можете создать poweruser с большинством способностей. Самая большая проблема, которую я нахожу в команде, это люди, которые применяют исправления или устанавливают дополнительное программное обеспечение, которое они не прояснили с помощью управления. В прошлый раз кто-то установил ReSharper, а затем пожаловался, что машина движется медленно. У них был компьютер объемом 2 ГБ, а для работы ReSharper 5 требуется минимум 4 ГБ, чтобы работать поверх Visual Studio 2010.

Дополнительно - учиться развиваться без использования мышки. Это радикальная концепция, которую я знаю, но мышь работает медленнее, чем сочетания клавиш. Если значок не находится в самом углу страницы, поиск значка и его нажатие занимает в среднем одну или две секунды. Запоминание ярлыка происходит быстрее.

0 голосов
/ 27 мая 2010

Если вы действительно хотите упростить процесс, взгляните на концепцию непрерывного развертывания, которая становится очень популярной. Вот хорошее вступительное сообщение ; Общая цель состоит в том, чтобы развернуть прямой переход от разработки к производству с использованием строгой автоматической проверки для устранения ошибок.

Поначалу установка полного непрерывного развертывания может показаться немного сложной, но вы могли бы начать с того, чтобы попробовать этот процесс, чтобы перейти от разработки к QA.

0 голосов
/ 26 мая 2010

Я бы не справился с этим, удалив привилегии локального администратора, это принесет больше вреда, чем пользы, но я бы порекомендовал настроить сервер сборки для проверки сборок в контролируемой среде. Я выбрал набор инструментов, который, как мне показалось, очень хорошо работает для меня и моей команды из примерно десятка добровольцев:

  • JetBrains TeamCity - непрерывная интеграция и сборка, а также модуль юнит-тестирования
  • Atlassian Jira - отслеживание проблем и управление проектами
  • Atlassian Fisheye / Crucible - обзоры кода и общие метрики кода.
  • Сервер VisualSVN - контроль исходного кода
  • Клиент VisualSVN (интеграция с Visual Studio, стоит того).
  • JetBrains ReSharper - производительность труда программиста и некоторые аккуратные инструменты модульного тестирования.

Я не могу рекомендовать эти инструменты достаточно высоко. TeamCity решает вашу проблему «мы обнаружили ошибку после отправки», убирая ваши сборки с машин разработчиков и собирая их в чистой контролируемой среде. Он также запускает модульные тесты и гарантирует, что у вас всегда будет рабочая сборка (путем присвоения имени и опровержения прерывателя сборки).

Crucible - это ценный продукт, который позволяет легко и беспрепятственно выполнять рецензирование кода, чтобы вы могли убедиться, что они выполняются правильно.

Другие пункты, которые, я думаю, говорят сами за себя, все они вносят свой вклад в «лучшие практики», которые значительно продвинут ваш магазин до «теста Джоэла». У Atlassian есть предложение на 10 лицензий по 10 долл. США на некоторые из их продуктов, которое трудно превзойти.

Все это, несмотря на это, решение ваших проблем развития будет, по крайней мере, частично культурным. Вы можете использовать эти (или другие) инструменты на месте, но вам понадобится участие команды и руководства, и вам нужно будет учитывать свои методы, чтобы разработчики могли их использовать. Некоторое переобучение может быть затруднено, потому что неаккуратные разработчики обычно не любят, когда их заставляют играть. Я бы начал с сервера сборки и настаивал на том, что никакой код не может быть выпущен, если он не получен из автоматической сборки. Из этого получится много хороших практик. Вы можете рассмотреть возможность применения модульного тестирования и проверки кода, как и когда это подходит для вашей организации, но планируйте сделать это с самого начала.

0 голосов
/ 26 мая 2010

Я не большой поклонник централизации разработчиков на сервер разработки. Люди должны иметь возможность редактировать и объединять, где бы они ни находились, с любой системой, в которой они оказались. Какую проблему вы пытаетесь решить с этим? Может быть другое решение этой проблемы.

Сервер QA является обязательным. Ваша команда QA нуждается в месте, куда они могут пойти, чтобы сломать вещи, которые не повлияют на развитие.

Я предполагаю, что на сервере "TEST" это место, где можно разместить ночные сборки, чтобы разработчики могли провести тестирование перед выпуском в QA? Это очень хорошая идея, и, как упоминает Кен, ночные сборки на задании сборки для этого сервера могут быть использованы для содействия этому процессу.

0 голосов
/ 26 мая 2010
  1. Не. Это будет PITA и снизит производительность ваших разработчиков, повлияв на их способность выполнять быстрое развертывание, отладку своего кода и запускать параллельно несколько версий их кода.
    Конечно, вы должны заставить их развиваться как не-администраторы локально, но это другая история.
  2. Да. Фактически, я бы пошел дальше и заставил весь код, который проверяется, в главном репозитории проходить автоматическое развертывание на чистом сервере. У вас также должна быть одна такая среда, в которой также будет развернут код, который будет передан в производство.
  3. Да. Это часть п.2.

Первая задача, над которой вы хотите поработать, - убедиться, что все продукты, над которыми работает ваша компания, имеют ** пакет развертывания, который вы можете развернуть в автоматическом режиме на скрипучей чистой машине **. Если у вас нет такого пакета, у вас будет много проблем с попыткой форсировать вышеуказанный процесс, поскольку каждое развертывание потребует ручного вмешательства, которое будет стоить вашей компании столько времени и ресурсов, что никто не будет об этом беспокоиться. 1010 *

Вторая задача - создать окончательную конфигурацию для серверов развертывания и подготовить образы, которые каждый может развернуть на локальной или виртуальной машине. Это будет базой для любого вашего тестирования и должно быть как можно ближе к реальной производственной конфигурации.

...