svn стратегии развертывания для нескольких групп разработчиков (не совместно расположенных), работающих над разными компонентами одного проекта
Наш проект - это система управления контентом, поддерживающая несколько десятков наших веб-сайтов. Группа разработчиков начинала с малого и располагалась в одном месте, и мы имели дело с довольно стандартной стратегией кодирования / развертывания.
Мы кодировали магистраль и настаивали на чистой магистрали. Каждые несколько дней мы помечали транк и развертывали его на тестовом сервере. Если все получится, мы развернемся в производственной среде и двинемся дальше.
Некоторое время это работало хорошо, пока команда не выросла. Мы часто сталкивались с ситуациями, когда помеченная ревизия имела проблемы, которые необходимо было исправить перед переходом в рабочую среду. Пока ответственный разработчик работал над этими исправлениями, у нас были другие разработчики, которые вносили изменения в магистраль. После того, как исходные исправления разработчика были завершены, новые коммиты, которые были добавлены, должны были бы уйти, что еще больше задержит сборку, потому что теперь требуется дополнительная проверка.
Пытаясь исправить это, мы создали отдельный ствол, используемый исключительно для выпусков. Люди работали в основном стволе, а затем просили менеджера проекта или руководителя разработки объединить их изменения в ствол выпуска.
Это работало какое-то время, пока команда не стала еще больше и разобщенной. У нас есть команды из 3-5 человек, работающих в 4 географических точках - одни над одними и теми же компонентами, другие над разными компонентами с разными приоритетами и графиками выпуска. Это была в значительной степени постоянная работа и стала кошмаром для человека, управляющего сборками.
Пытаясь обойти это, мы начали создавать «ветки выпуска» на основе того, что было в последней версии тега Production. Люди будут отдавать туда ТОЛЬКО то, что готово для тестирования и перехода в производство. Другие будут фиксироваться в стволе, пока не наступит их очередь слиться. Это сняло бремя слияния и разрешения конфликтов с менеджера сборки и на человека, владеющего кодом.
Это работало около недели, пока нам не пришлось делать несколько «высокоприоритетных аварийных» выпусков. Фактически это означало, что мы должны:
- Создать ответвление от последнего производственного тега
- Добавить аварийный материал в эту ветвь
- Пометить эту ветвь и выпустить его в Производственный
- Объединить все внесенные изменения в этой ветке в обычную «ветку выпуска», которая находится в QA.
Это происходит каждый день. Иногда два раза в день.
Я попытался немного связать это с проектом с открытым исходным кодом, где повсюду есть разработчики, которые даже не знают друг друга, и они все еще, кажется, обходятся ... но это сравнение разваливается, когда новые стабильные, проверенные, производственные сборки ожидаются для «общественного» потребления несколько раз в неделю (или день). Если ежедневная сборка Firefox содержит, например, беспорядок, по крайней мере, пользователи могут вернуться к предыдущей версии или использовать последнюю стабильную версию. Это не относится к нашим пользователям. Если наш выпуск не идеален, они не могут работать.
Предыстория завершена, теперь я задаю вопрос:
Учитывая среду, где ...
- Разработчики повсюду и работают над разными компонентами.
- Изменения в некоторых компонентах могут ждать неделю, прежде чем будут выпущены, другие не могут ждать даже дня.
- Приложение является критически важным, и изменения должны быть протестированы и стабильны перед выпуском.
... какие предложения или альтернативные рабочие процессы вы можете порекомендовать, чтобы продвигать более разумный процесс, в котором большая часть бремени лежит не на одном человеке?