Mój zespół obecnie stosuje dość prosty proces rozgałęziania / wdrażania, który wygląda następująco:
┌────────┐ ┌────┐ ┌──────┐
Environments: │ DEV │ │ QA │ │ PROD │
└────────┘ └────┘ └──────┘
▲ ▲ ▲
│ │ │
┌────────┐ ┌────┐ ┌──────┐
Builds: │ DEV │ │ QA │ │ PROD │
└────────┘ └────┘ └──────┘
▲ ▲ ▲
│ │ │
┌────────┐ ┌────┐ ┌──────┐
Branches: │ master │ │ qa │ │ prod │
└────────┘ └────┘ └──────┘
Każde środowisko ma swoją gałąź (używamy git ) i własną kompilację, która korzysta z tej gałęzi. Kiedy chcemy awansować z jednego środowiska do drugiego, na przykład z DEV do QA, łączymy mastergałąź qai rozpoczynamy nową kompilację QA (która jest następnie automatycznie wdrażana w środowisku QA).
Zastanawiamy się nad przejściem na nowy proces, który wyeliminowałby tworzenie dedykowanego oddziału i kompilacji dla każdego środowiska. Zamiast tego kompilacja pojedynczego wydania stworzyłaby „pakiet wdrożeniowy”, który można by następnie wdrożyć w dowolnym środowisku. Wyobrażamy sobie, że typowy przepływ pracy wyglądałby mniej więcej tak:
┌────────┐ ┌────┐ ┌──────┐
Environments: │ DEV │ ──► │ QA │ ──► │ PROD │
└────────┘ └────┘ └──────┘
▲
\
┌───────────────┐
Builds: │ release build │
└───────────────┘
▲
│
┌────────┐ ┌─────────┐
Branches: │ master │ │ release │
└────────┘ └─────────┘
Promowanie z jednego środowiska do drugiego nie byłoby już obsługiwane w ramach kontroli źródła; raczej wzięlibyśmy już skompilowane pliki binarne („pakiet wdrożeniowy”) i upuściliśmy je w nowym środowisku.
Ten nowy system pozwoliłby nam wdrożyć dowolną kompilację w dowolnym środowisku, co ma kilka zalet. Na przykład testowanie poprawek błędów PROD w DEV i QA jest banalne. Nasz obecny system nie zapewnia łatwego sposobu na zrobienie tego bez wycofywania gałęzi, czego oczywiście chcielibyśmy uniknąć.
Największą wadą tego nowego systemu jest to, że nie mamy już automatycznego sposobu śledzenia kodu w jakim środowisku. Jeśli musimy wprowadzić poprawkę w PROD, nie mamy już dedykowanego oddziału zsynchronizowanego z obecną produkcyjną bazą kodu. To samo dotyczy kontroli jakości - jeśli chcemy wprowadzić szybką zmianę do kontroli jakości bez pogłębiania trwającej pracy master, nie mamy już gałęzi odzwierciedlającej bieżący stan środowiska kontroli jakości.
Jak możemy śledzić, jaki kod znajduje się w każdym środowisku?
Niektóre opcje, które rozważamy:
- wykorzystanie tagów git do śledzenia, które zatwierdzenie znajduje się w danym środowisku
- osadzanie zatwierdzenia git używanego przez kompilację w każdym pakiecie wdrażania