Нахождение правильного рабочего процесса git

Question

Мы небольшая команда веб-приложений (менее 10). Наша среда состоит из 3 тестовых сред и производства для десятка приложений. Одна из наших сред тестирования предназначена для одобрения функций / исправлений (назовите ее Dev), а две другие - на скрытых средах тестирования, одна для Dev (назовите Pre-Dev) и одна для производства (назовите Pre-Production). Это помогает нам убедиться, что функция / ошибка достаточно проверена. Каждая функция проходит через эти 3 тестовые среды, прежде чем перейти к производству, а некоторые функции могут быть утверждены заказчиком в течение нескольких месяцев.

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

В настоящее время у нас есть одна ветвь для каждой среды, и мы используем запросы извлечения из наших ветвей Feature / Bugfix, чтобы поочередно распространять наш новый код по каждой ветке. При выпуске что-либо в ветке Pre-Prod будет сдавлено в Prod и выпущено. Мы смотрим на рабочий процесс на основе соединительных линий, но я думаю, что наше долгосрочное тестирование задерживает нас. У кого-нибудь есть идеи?

Answer 1

Как я понял, вам нужно 2 вещи:

1. Более чистый (более простой) git-flow
2. Строгое отделение конфига от кода

---

1. Простейший git flow

Feature / Bugfixes

• Все в ветви master можно развернуть
• Чтобы поработать над чем-то новым, создайте ветвь с именем с описательным именем от master (например: bugfix_login_error)
• Локально фиксируйте эту ветвь и регулярно отправляйте свою работу в одноименную ветвь на сервере
• Если вам нужна обратная связь или помощь, или вы считаете, что ветка готова к объединению, откройте запрос на удаление (или запрос на объединение в GitLab).
• На данный момент rebase для получения последних изменений мастера в ветке feature / bugfix.
• После того, как кто-то еще проверил и подписал эту функцию, вы можете объединить ее в master

Hotfixes

• Ветви исправлений создаются из ветки master.
• Каждая ветвь исправлений должна сливаться обратно с главной и всеми ветвями функций / исправлений

Идея состоит в том, чтобы сделать так, чтобы все в команде действительно понимали, то есть единственный способ уменьшить человеческие ошибки. См. github-flow для более подробной информации об этом подходе.

Правило большого пальца: ПОЦЕЛУЙ (Храни это глупо)

---

2. НЕ храните одну ветвь на среду

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

См. Приложение с 12 факторами для более подробной информации об этом подходе.

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