Если у вас есть работающий сервер и сервер разработки, я бы сделал что-то в этом роде.
Прежде чем начать цикл разработки, я бы по крайней мере имел две ветви:
- Мастер - сервер разработки работает в этой ветке
- Стабильный - на этой ветке работает живой сервер.
Таким образом, если разработчик получит билет или рабочее задание, он / она выполнит следующие действия:
- мастер происхождения git pull
- git branch featureBranch (называемый идентификатором заявки или хорошим описанием рабочего задания)
- git checkout featureBranch
- Внесите изменения, которые позволят выполнить желаемое изменение. Совершайте так часто, как это необходимо. Сделайте это, потому что вы создадите ценную историю. Например, вы можете попробовать подход к проблеме, и если она не работает, откажитесь от нее. Если через день вы видите свет и хотите повторно применить решение, оно в вашей истории!
- Когда функция полностью разработана и протестирована на месте, проверьте мастер.
- git merge featureBranch
- git push origin master
- Протестируйте внесенные изменения на сервере разработки. Это момент для запуска каждого теста, о котором вы только можете подумать.
- Если все работает, объедините функцию или исправьте в стабильную ветку. Теперь изменения доступны для ваших клиентов.
Получение кода на сервере
Обновление серверов не должно быть проблемой. По сути, я бы настроил их как пользователей, как разработчиков. В моей компании мы настроили серверы только для чтения. По сути, это означает, что серверы никогда не могут выдвигать что-либо, но могут всегда вытягивать Настроить это не так просто, так что вы также можете создать простой веб-интерфейс, который позволяет только git pull. Если вы можете помешать вашим разработчикам делать что-то на живых реализациях, вы в безопасности:)
[EDIT]
В ответ на последние вопросы, заданные в комментариях к этой реакции:
Я не знаю, правильно ли я понимаю ваш вопрос, но в основном (немного упростил) я так и сделал бы, если бы я был в вашей обуви.
Машина тестирования (или webroot, который действует как реализация тестирования) имеет исходный код, основанный на git-репозитории с проверенной веткой master. При создании этого хранилища вы можете даже удалить все другие ссылки на все остальные ветви, так что вы будете уверены, что не сможете оформить неправильную ветку в этом хранилище. Так что в основном на тестовой машине есть Git-репозиторий с только главной веткой, которая извлечена.
Для живых серверов я бы сделал то же самое, но на этот раз с проверенной стабильной веткой. У разработчика должен быть клонированный локальный репозиторий, в котором существуют все ветви. И локальная реализация программного обеспечения, которое вы, ребята, создаете. Это программное обеспечение получает свой источник из локального репозитория git. Другими словами: из текущей проверенной ветки в этом хранилище.
Фактическое кодирование
Когда требуется новая функция, локальная ветвь функции может быть создана на основе текущего мастера. Когда ветка извлечена, изменения могут быть внесены и проверены разработчиком локально (поскольку программное обеспечение теперь работает на источнике ветки функции).
Если кажется, что все в порядке, изменения объединяются из функциональной ветви в master и отправляются на ваш «git machine». "твой github" так сказать. Теперь тестирование может привести к изменениям, поэтому QA может выполнить каждый необходимый тест. Если они решат, что все в порядке, разработчик может объединить изменения из основного в стабильный и снова нажать.
Все, что осталось сейчас, это тянуть с ваших живых машин.