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