Wpis z mikrobloga

Pracujemy nad porządnym gitflow, który chcemy spiąć z CI/CD i aktualnie pojawił się pewien problem.

Mianowicie - mamy dwa branche: pretest i master. Developerzy mergują branche feature do pretestu, tam są puszczane automaty, jeśli testy przejdą to jest robiony automatyczny merge do mastera.

Mamy 4 środowiska na które rzutują 4 branche:
- pretest env - pretest branch (na nim działają tylko automaty)
- test env - master (automatyczne podegranie po przejściu automatów na pretest env)
- stage env - otagowany tagiem (pre-release) kod na masterze
- prod env - otagowany tagiem (prod) kod na masterze

Problem powstaje, gdy chcemy zrobić paczkę "pre-release" i wziąć się za jej testowanie. Na środowisku test kod jest cały czas dostarczany, przez co ciągle coś tam się zmienia. Stage miał być środowiskiem z już przetestowaną paczką do testów biznesowych, także słabo trochę pchać tam nieprzetestowany w pełni kod.

Jak to u Was wygląda? Możecie się podzielić doświadczeniami w tym temacie? :) Co można tu zmienić/poprawić?

Z góry dziękuję za wszelkie wsparcie.

#programowanie #git #github #jenkins #testowanieoprogramowania #testowanie #ci #cd
  • 5
automatyczny merge

A co z konfliktami? :D

U nas jest develop i master
Wszystko jest puszczane po prostu jako gałęzie na gita. Jak przetestuje się gałąź, doczepiamy(merge lub rebase, zazwyczaj merge) do devela.
Master to aktualna wersja na produkcji
ciekawe

przetestuje się gałąź


@Prism2772: Na poziomie gałęzi odpalacie same testy automatyczne różnych poziomów i, jeśli przejdą, to uruchamiany jest merge do developa, czy testujecie też ręcznie już na tym etapie?

Master to aktualna wersja na produkcji


@Prism2772: to chyba najnormalniejsze podejście
@Fristo: testy automatyczne będą u nas "w przyszłości" :D
Robimy na gałęzi merge z developa i wtedy jest test :)
I jak jest okej, to gałąź przyłączamy do developa.
Nie wiem na jakim poziomie patologii to jest, ale to moja pierwsza praca, więc trudno mi się tutaj wypowiadać, czy to dobrze, czy źle :)