Одиночная упаковка в трубопроводе непрерывной подачи при параллельном строительстве

Question

Моя компания использует Jenkins для непрерывной интеграции, и я пытаюсь перейти на компакт-диск. Я использую git hub как репозиторий кода. Сейчас мы объединяем ветки функций в среду uat, и когда определенная функция была принята, ветвь функции будет объединена с нашей производственной ветвью. Это, очевидно, опасно, потому что два изменения могут быть протестированы вместе и развернуты отдельно. В идеале у нас был бы пакет, протестированный и развернутый без перестройки, но у меня возникли проблемы с тем, как это возможно. Если два человека работают по двум различным функциям, первый закончен, упакован и переходит в тестирование, второй закончен и упакован без первого? Но тогда как я могу развернуть пакет без аннулирования тестирования другой функции? Я не уверен, как правильно интегрировать функции с одним развертываемым пакетом.

Любая помощь была бы принята с благодарностью.

Далее, Если посмотреть на http://ptgmedia.pearsoncmg.com/images/chap5_9780321601919/elementLinks/fig5_6.jpg моего беспокойства в том, что при регистрации по прибытию 1 может быть развернута, когда она проходит приемочные испытания, и что пакет будет развернут, но что, если приемочные испытания не удались? Check-in 5 содержит ту же проблему, что и check-in 1, поэтому никакое развертывание в производство не может быть выполнено до тех пор, пока регистрация 1 не будет исправлена ​​или не удалена. Удаление изменений будет раздражать, так как может быть удалено несколько коммитов, а тестирование fix + может занять много времени.

Answer 1

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

Ветвление любого вида - это все, что касается изоляции и так что в корне противоречит CI. Особенность ветвления и CI противоположны.

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

Извините, но вы не можете иметь оба, они противоположности!

Answer 2

Что касается разницы в времени цикла исправлений и менее важных вещей, вы просмотрели функции переключения? http://martinfowler.com/bliki/FeatureToggle.html

Answer 3

Если вы хотите сделать Непрерывную доставку, тогда разветвление - это не-нет. Ну, в основном. Релизы должны быть помечены в SCM, исправление применяется для выпуска и объединения в HEAD.

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

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

Если две функции должны быть развернуты одновременно, то я предполагаю, что сначала вы должны использовать принцип TDD для создания теста FAILING, а затем реализовать код, чтобы он стал зеленым. Проверьте, что тест, так что никакая сборка не может двигаться вперед, пока вы ее не реализуете. Это абсолютно ясно, что эта сборка не предназначена для производства, поскольку эта функция не завершена.Не очень хорошая идея для этого теста быть CI, но на последнем этапе тестирования ... при условии, что у вас есть несколько этапов тестирования!