Z której gałęzi korzystasz, aby wprowadzić zmiany w…

develop lub specjalistyczna gałąź funkcji/bug, która następnie jest scalana z develop.

Opcje:

develop: Główna gałąź rozwoju, do której integruje się wszystkie nowe funkcje i poprawki. Idealna do ciągłej integracji i testowania najnowszych zmian.
Gałęzie Feature/Bugfix: Dla dużych funkcji lub pilnych poprawek można używać oddzielnych gałęzi. Po zakończeniu pracy są one scalane z develop. Testowanie na środowisku testowym może odbywać się zarówno po scaleniu z develop, jak i bezpośrednio z gałęzi, w zależności od procesu.

Wybór konkretnej strategii zależy od przyjętej w zespole strategii gałęzi (Gitflow, Trunk-Based Development itp.) oraz konfiguracji pipeline'ów CI/CD. W większości przypadków, środowisko testowe automatycznie wdraża zmiany z gałęzi develop przy każdym commicie.

Przykład konfiguracji CI/CD (Jenkins Groovy Script):

// Pipeline wywoływany przy commicie na gałęzi develop
pipeline {
    agent any
    stages {
        stage('Checkout') {
            steps {
                checkout scm
            }
        }
        stage('Build') {
            steps {
                sh './build.sh' // Budowa aplikacji
            }
        }
        stage('Deploy to Dev Test') {
            when {
                branch 'develop' // Tylko z develop
            }
            steps {
                sh './deploy_to_dev_test.sh' // Wdrożenie na środowisko testowe
            }
        }
        stage('Run Automated Tests') {
            steps {
                // Uruchomienie testów UI/API na środowisku testowym
                sh './run_automated_tests.sh'
            }
        }
    }
}

Przykład konfiguracji CI/CD (GitLab CI/CD):

# gitlab-ci.yml
stages:
  - build
  - deploy
  - test

build:
  stage: build
  script:
    - ./build.sh # Budowa aplikacji

deploy_dev_test:
  stage: deploy
  only:
    - develop # Tylko z develop
  script:
    - ./deploy_to_dev_test.sh # Wdrożenie na środowisko testowe

run_automated_tests:
  stage: test
  script:
    - ./run_automated_tests.sh # Uruchomienie testów UI/API
  needs: ["deploy_dev_test"] # Po udanym wdrożeniu

W przypadku użycia gałęzi feature, pipeline może być skonfigurowany tak, aby wdrażać tymczasowe środowiska do testowania tych gałęzi:

Przykład GitLab CI/CD z dynamicznymi środowiskami:

# gitlab-ci.yml
stages:
  - build
  - deploy
  - test
  - cleanup

build:
  stage: build
  script:
    - ./build.sh

deploy_feature_env:
  stage: deploy
  except:
    - develop
    - main
  script:
    - ./deploy_dynamic_env.sh $CI_COMMIT_REF_SLUG # Wdrożenie tymczasowego środowiska
  environment:
    name: review/$CI_COMMIT_REF_SLUG # Nazwa dynamicznego środowiska
    url: http://$CI_COMMIT_REF_SLUG.test.example.com # URL środowiska
    on_stop: cleanup_feature_env

run_feature_tests:
  stage: test
  except:
    - develop
    - main
  script:
    - ./run_tests_on_dynamic_env.sh http://$CI_COMMIT_REF_SLUG.test.example.com

cleanup_feature_env:
  stage: cleanup
  variables:
    GIT_STRATEGY: none
  script:
    - ./cleanup_dynamic_env.sh $CI_COMMIT_REF_SLUG
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    action: stop

W ten sposób, dla środowiska deweloperskiego, najczęściej używa się gałęzi develop, zapewniającej ciągłe testowanie najnowszych zmian. W zależności od procesu, mogą być również używane gałęzie feature lub bugfix do testowania punktowego.

Z której gałęzi korzystasz, aby wprowadzić zmiany w środowisku testowym rozwoju?