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

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

Некоторые особенности:

• GIT на BitBucket
• Jenkins для развертывания по сценарию в Azure

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

Похоже, у вас есть несколько проблем здесь:

1. Определение функций для конкретной версии

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

2. Стратегии ветвления

Git-flow - простой ответ на подобные проблемы, и часто люди используют вариант git-flow, даже если они не знают, что это такое. Я не собираюсь говорить, что это универсальное решение для всех проблем, но это очень помогает.

Похоже, у вас возникла проблема с недетерминированными стратегиями выпуска, когда функции одобрены как scattershot, и что-то, что начало разрабатываться давным-давно, может быть выпущено после чего-то, что началось совсем недавно - функции скачкообразного изменения.

Долгоживущие функциональные ветки или ветки одновременного выпуска, вероятно, являются лучшим ответом для такого рода проблем. Объедините (или перебазируйте, если вам это удобно) последние новости от мастера в свои долгосрочные ветви. Будьте осторожны, объединяйте только те функции, которые уже работают, в противном случае вы столкнетесь с проблемами, с которыми вы столкнулись сейчас (слишком много смешанных функций в одной ветви).

Ветви «исправлений» или «исправлений» являются неотъемлемой частью этого процесса; используйте их для небольших одноразовых исправлений с коротким циклом контроля качества.

Из вашего описания может быть даже лучше не поддерживать официальную ветку «разработка». Скорее, разветвите все функции от главного и создайте объединенные выпуски после определения выпуска.

3. Среды

Не совмещайте ветки git с вашей средой, за исключением production == master. Ветвь 'развития' должна считаться сломанной. Ветви релизов отправляются в тестовые среды, будь то среда QA или промежуточная среда. Если вам нужно, отправьте конкретную ветвь функции в среду.

Если у вас есть более одной ветви функций, которую нужно выпускать отдельно, но в то же время тестировать ..... ¯ \ _ (ツ) _ / ¯ .... раскрутить другой сервер? Может быть, объединить их в одноразовую ветку ... зафиксировать исправления / изменения в исходных ветках и заново объединить в одноразовую ветку; сделать окончательное утверждение и UAT по отдельным веткам релиза.

4. Удаление неподтвержденных функций из ветки

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

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

Удачи.

Вот идея, прекратить использование веток релиза. Вместо этого начните встраивать переключатели функций и управлять ими через конфигурацию. Таким образом, вы всегда объединяете ветви функций в master, и никогда не должно возникать вопроса о том, какая версия находится в тесте или в prod. Если у вас есть вопрос о том, какие функции / реализации активны в среде, просто проверьте файл конфигурации.

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

Если вам нужен лучший контроль, чем этот, разделите Test на сервер разработки и сервер Acceptance Testing и координируйте те ветви, которые будут отправлены на сервер Acceptance Testing с группой тестирования. Кто-то может быть ответственным за запуск окончательного развертывания от приемочного тестирования до производства.

Работа накапливается

Это универсальная проблема в моем опыте. Я обращаюсь к этому с:

• Сильное управление выпуском функций владельцем продукта
• Убедитесь, что ветки удаляются при объединении
• Ограничение незавершенного производства (с ограничениями на столбцы в Jira)
• Ежеквартальный обзор старых томных билетов, как ошибок, так и функций
• Ретроспективы для обсуждения компонентов проблемы
• Постоянное поощрение за просмотр кода всеми
• Возможность сопряжения для решения давних билетов и проблем
• Ежеквартальные встречи для проверки и очистки старых билетов
• Командный подход к тесному взаимодействию разработчиков, продукта и QA / QE
• Хорошие отчеты и инструменты, чтобы сделать новые возможности продукта и отставание очевидными
• Просмотр сессий, чтобы пройти через старые ветви и удалить их

ветви

Вам нужно несколько веток, чтобы контролировать этот процесс:

• особенность : это ветви рождаются от мастера. Используйте какое-либо приложение для управления проектами, чтобы идентифицировать каждую ветвь функции с определенной задачей. Пер Например, если вы используете TRAC, вы закончится , если ветви , как: 1234-user-crud, 1235-bug-delete-catalogи т.д. Определите ваши коммиты с номером задания тоже, это поможет вам много , когда у вас есть проблемы в слияниях (вы будете).
• test : все выполненные функциональные ветви будут объединены с тестовой веткой. Вы никогда не объединяете тестовую ветвь с какой-либо веткой функций , потому что вам не нужен код от других функций, которых нет в производстве (master). То же самое относится и к releaseветке.
• выпуск : когда вы решаете, какие протестированные функции могут быть в производстве, вы объединяете эти ветви (снова ...) в эту ветку. Вам необходимо снова протестировать все функции, потому что это объединение может принести новые проблемы. Когда релиз протестирован и готов, вы объединяете эту ветку с master и создаете тег на master для версии.
• master : содержит только производственный код

Смотрите поток мерзавцев:

                              |FEAT_2|
                                  |
                             .---C06<-------.---------.
                            /                \         \
                           /   |FEAT_1|        \         \
                          /       |            \         \
                         /    .--C07<--.--------\---------\---------.
                        /    /          \        \  |TEST| \         \
                       /    /            \        \    |    \         \
                      /    /        .-----`--C09<--`--C10    \         \ |RELEASE|
                     /    /        /                          \         \    |
    <v4.6.0>        /    /        /                       .----`--C11<---`--C12<--.
       |           /    /        /                       /                         \
C01<--C02<--C04<--´----´--------´-----------------------´---------------------------`--C13
 |           |                                                                          |
<v4.5.0>  <v4.6.1>                                                                   |MASTER|
                                                                                        |
                                                                                     <v4.7.0>

Среды

Очень просто:

• test : эта среда использует тестовую ветку.
• релиз : эта среда использует фактическую ветку релиза.

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

Проблемы

Самая большая проблема в этом процессе - слияния.

Вам нужно переделать те же слияния в testи release. Это будет больно, если в коде будет сделан хороший рефакторинг, такой как удаление класса, методы перемещения / переименования и т. Д. Поскольку вы не можете получить код из test(или release) ветви в ветвь функции, коммиты слияния могут быть разрешены только в test(или release). Таким образом, вы в конечном итоге решения те же конфликты в двух различных отраслях, возможно производить различный код в каждом слиянии и, в будущем, вы обнаружите , что тестовая команда будет необходимо протестировать возможности дважды: в testи releaseветви, потому что каждый слияния может привести к различным ошибкам.

Другая проблема - testветка. Вам нужно время от времени «перерабатывать» эту ветку (удалять и создавать новую master), потому что некоторые старые ветви (или старые слияния, слитые ветви, которые были удалены) могут принести много проблем для нового кода, сильно расходится с тем, что в master. В этот момент вам нужен контроль над тем, какие ветви вы бы хотели снова объединить в test.

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

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

ИМХО правильный процесс будет:

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

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

• Я не уверен, что у вас есть отдельные группы разработчиков и разработчиков. Если вы это сделаете, убедитесь, что Dev и QA присутствуют на совещаниях по планированию спринта и оценке. В одной из моих предыдущих компаний мы позаботились о том, чтобы количество очков истории, которые мы назначили для истории, учитывало как усилия по разработке, так и тестирование. (Вы также можете теоретически иметь две отдельные оценки для разработки и обеспечения качества, но в любом случае вам нужно, чтобы ваша оценка включала обе; время, необходимое для истории, - это время, необходимое для ее фактической доставки). Даже если у вас нет отдельной группы QA, убедитесь, что вы включили тестирование в свои оценки.
• В том же духе, что и выше, заранее договоритесь о том, сколько историй вы собираетесь включить в тот или иной спринт. Количество баллов, которые вы принимаете, зависит от суммы, которую ваши разработчики могут закончить в своем спринте, и количества предметов, которые QA может протестировать в своем спринте. (Конечно, я предполагаю, что спринты QA стоят за спринтами Dev, но вы можете адаптировать это к своему процессу). Если ваши разработчики могут набрать 200 баллов, но ваш QA может набрать только 150 баллов, очевидно, вы можете набрать только 150 баллов, прежде чем работа начнет «накапливаться», и вы получите случай, подобный тому, что вы описываете. (В таком случае вы можете изучить причину контрольно-пропускного пункта, чтобы попытаться смягчить его).
• Никто ничего не подталкивает к QA, пока все, что в настоящее время в QA, не протестировано и не доставлено .
• Полная функция - это то, что было протестировано и доставлено. Если это не доставлено, это не сделано.
• Очевидно, вы хотите попытаться сделать это по какому-то фиксированному графику. Одной из идей непрерывной интеграции и гибкой разработки является итерация. По определению, итерация влечет за собой частую доставку. Частые интеграции и доставка сводят к минимуму риск каждого из них.

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

Подводя итог: доставляйте в QA только тогда, когда вы закончите тестирование и поставку старых функций.

Когда «все проверено и одобрено», разверните то, что было проверено и одобрено для производства. Это может быть определенный коммит или конкретный артефакт сборки, сгенерированный Дженкинсом.

Не должно иметь значения, что последующие коммиты в той же ветке еще не проверены.