Я думаю, что вам нужно изменение макета хранилища. Если я правильно понимаю, ваш репозиторий выглядит так:
Mainline
|
-- Live branch January (v 1.0)
|
-- Live branch April (v 2.0)
|
-- Live branch July (v 3.0)
Таким образом, каждая из веток содержит все ваши сайты (сотни), а также папки для общего кода.
Нет научного способа точно определить вероятность появления ошибки после выпуска, но давайте рассмотрим два наиболее важных фактора:
- Количество строк кода зафиксировано за единицу времени. Вы не можете / не захотите глобально изменить это, поскольку это результат производительности разработчика.
- Test-Coverage , иначе говоря, как часто исполняется код ДО начала работы и какая часть вашей кодовой базы задействована. Это легко можно изменить, дав людям больше времени для тестирования перед выпуском или внедрив автоматизированные тесты. Это проблема ресурсов.
Если ваша компания не хочет тратить деньги на дополнительное тестирование или уменьшать частоту выпусков (не обязательно производительность!), Вам действительно нужно будет найти способ выпускать меньше изменений, эффективно уменьшая количество измененных строк кода на выпуск.
В результате этого понимания, что все разработчики присоединяются к одной и той же ветке и работают оттуда несколько раз в день, это не хорошая идея, не так ли?
Требуется повышенная изоляция.
Изоляция в большинстве систем контроля версий осуществляется с помощью
- Увеличение числа ревизий на атомарный коммит
- Ветвление
Вы можете попытаться реализовать решение, которое упаковывает изменения из нескольких ревизий в пакеты выпуска, подобно тому, как это делает система контроля версий "Perforce". Я бы не стал этого делать, так как ветвление всегда проще. Помните о принципе KISS.
Так как же может помочь ветвление?
Вы можете попытаться изолировать изменения, которые должны вступить в силу сегодня, от изменений, которые могут вступить в силу завтра или на следующей неделе.
Итерационные ветви
Mainline
|
-- Live branch July (v 3.0)
|
-- Monday (may result in releases 3.0.1 - 3.0.5)
|
-- Thuesday (may result in releases 3.0.6 - 3.0.8)
|
-- Wednesday (may result in releases 3.0.9 - 3.0.14)
Людям нужно больше задумываться о «нацеливании» своих изменений на нужный выпуск, но это может привести к не столь срочным изменениям (особенно в отношении разделяемого / библиотечного кода), которые дольше остаются вне выпуска и внутри живой ветки, где случайно или систематическое тестирование они могут быть обнаружены до запуска в действие (см. охват тест-фактор).
Конечно, требуется дополнительное слияние, а иногда и черчение изменений из живой ветки в ежедневную ветку.
Теперь, пожалуйста, не принимайте меня слишком буквально с ежедневными ветками. В моей компании у нас есть 2-недельные итерации, и для каждой итерации ветвь релиза, и для ее поддержки достаточно накладных расходов.
Вместо выделения по дням вы можете попробовать выделить по продукту / сайту.
Филиалы проекта
Mainline
|
-- Live branch July (v 3.0)
|
-- Mysite-A (released when something in A changed and only released to the destination of A)
|
-- Mysite-B
|
-- Mysite-C
В этом сценарии код одного сайта И весь необходимый общий код и библиотеки будут находиться в такой ветви сайта.
Если необходимо изменить общий код для того, чтобы что-то работало на сайте A, вы можете изменить только общий код на сайте A. Вы также объединяете это изменение, чтобы любой мог его отследить. Циклы захвата могут быть намного длиннее, чем релизы, поэтому у кода есть время для «созревания».
В процессе развертывания / сборки вы должны убедиться, что общий код сайта-А, конечно, НЕ перезаписывает общий код сайта-Б. Вы эффективно «разветвляете» свой общий код со всеми вытекающими последствиями (несовместимость, накладные расходы на интеграцию командных изменений).
Время от времени следует выполнять принудительное слияние с live-ветвью (возможно, вы захотите переименовать и то), чтобы интегрировал все изменения, которые были сделаны в совместно используемом коде. Я полагаю, что ваша трехмесячная итерация все равно заставит вас сделать это, но вы можете обнаружить, что 3 месяца - это слишком долго для беспроблемной интеграции.
Третий подход - самый экстремальный.
Ветви проектов и итераций
Mainline
|
-- Live branch July (v 3.0)
|
-- Mysite-A
|
-- Week 1
|
-- Week 2
|
-- Week 3
|
-- Mysite-B
|
-- Week 1
|
-- Week 2
|
-- Week 3
|
-- Mysite-C
|
-- Week 1
|
-- Week 2
|
-- Week 3
Это, безусловно, приносит огромные накладные расходы и потенциальную головную боль, если вы не обращаете внимания. С хорошей стороны, вы можете очень точно развернуть только необходимые изменения СЕЙЧАС для ЭТОГО Проект / Сайт.
Надеюсь, все это даст вам некоторые идеи.
Прикладной источник контроля много о контроле рисков для повышения качества продукции.
Хотя решение о том, какой уровень качества хочет обеспечить ваша компания, может быть не в ваших руках, но знание этого поможет вам решить, какие изменения предложить. Возможно, ваши клиенты будут довольны вашим качеством, и дальнейшие усилия по его повышению не амортизируют.
Удачи.
Christoph