Как перейти от «тайной интеграции» к непрерывной интеграции?

Question

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

В любом случае, как и любой ОГРОМНЫЙ проект, он состоит из множества компонентов на разных языках (например, не только корпоративный стиль Java или C #), а также многих графических и текстовых ресурсов. Теперь проблема в том, что когда я ищу интеграцию Continuos, я всегда нахожу лучшие практики и приемы, которые предполагают, что каждый начинает новый проект с нуля. Однако это не новый проект, поэтому мне было интересно, какие есть хорошие ресурсы для активного перехода с Arcane Integration на Continuos Integration:)

Заранее спасибо!

Answer 1

Здесь это в два простых (хах) шага.

1. Перейти на повторяемую сборку:
   1. Используйте контроль исходного кода, отметьте весь код.
   2. Создание и документирование всех инструментов, используемых для сборки (в основном, это версия компилятора). Повторяемое развертывание и настройка процесса для этих инструментов.
   3. Установите и четко документируйте любые ресурсы, которые необходимы для сборки, но не проверены (сторонние установки, пакеты обновления и т. Д.). Повторяемое развертывание и настройка процесса для этих зависимостей.
2. Прежде чем перейти к управлению исходным кодом, разработчики должны
   1. обновить свою рабочую копию
   2. успешно построить
   3. запускать и проходить автоматизированные тесты

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

Если вы сможете сделать все это, вы попадете в хорошее нормальное место.

Целями являются воспроизводимые процессы сборки и разработчики, которые подключены к тому, как их изменения влияют на сборку и других разработчиков.

Тогда вы можете пожинать бонусы, устанавливая более высокое соответствие:

• Разработчики устанавливают частую привычку коммитов. Код в рабочей копии никогда не должен быть старше 1 дня.
• Автоматизированный процесс сборки отслеживает контроль исходного кода для регистрации и доставляет результаты в место, где пользователи могут их принять (например, в тестовой среде, на веб-сайте предварительного просмотра или даже просто размещая .exe, где пользователь может найти его ).

Answer 2

Так же, как вы едите слона (по одному кусочку за раз) ;-) Для непрерывной интеграции требуется автоматическая сборка. Начни с этого. Автоматизируйте сборку каждого куска. Ant или NAnt - отличный способ сделать это. Пусть конструкция каждого компонента будет задачей NAnt. Тогда вся ваша сборка системы может агрегировать эти отдельные задачи.

Оттуда вы можете добавлять задачи для развертывания, для модульного тестирования и т. Д. Если вы хотите использовать технологию CI, вы можете подключить ее к вашей сборке NAnt.

Answer 3

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

Тогда ищите части для сценария.

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

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

Answer 4

Короче говоря: постепенно

Выберите структуру, которая будет работать в самых разных проектах.

Один за другим добавьте компоненты в каркас.

Если вы не знакомы с фреймворком, сначала воспользуйтесь несколькими более простыми компонентами, чтобы снизить риск их повреждения.

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

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

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

Answer 5

Я полагаю, что миграция на самом деле не вариант - решения с полусамом только ухудшат ситуацию.

Мой подход заключается в том, чтобы взять одного креативного инженера, который понимает процесс сборки, посадить его и сказать «Исправить это». Дайте ему неделю или две.

Конечной целью будет процесс, который запускается от начала до конца одной командой make.

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