Идеал dev/test/QA среда для разработки

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

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

Судя по серверу "ТЕСТ", я предполагаю, что это действительно место, где можно размещать ночные сборки, чтобы разработчики могли проводить тестирование перед выпуском в службу контроля качества? Это очень хорошая идея, и, как упоминает Cen, можно использовать ночные сборки задачи сборки для этого сервера, чтобы помочь этому процессу.

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

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

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

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

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

Остальные пункты, я думаю, не требуют пояснений, все они вносят вклад в "лучшие практики", которые продвинут ваш магазин далеко вперед в "Joel Test". Atlassian предлагает 10 лицензий за $10 на некоторые из своих продуктов, что трудно превзойти.

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

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

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

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

Зачем заставлять всех разрабатывать на сервере разработки? Не все ли ваши сотрудники работают в офисе?

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

Вы должны:

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

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

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

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