Kuru zaru izmantojat izmaiņu piemērošanai izstrādes…

develop vai specializēta funkcijas/bāzes šaka, kas vēlāk tiek apvienota develop.

Varianti:

develop: Galvenā izstrādes šaka, kurā tiek integrētas visas jaunas funkcijas un labojumi. Ideāli piemērota nepārtrauktai integrācijai un jaunāko izmaiņu testēšanai.
Feature/Bugfix šakas: Lielākām funkcijām vai steidzamiem labojumiem var tikt izmantotas atsevišķas šakas. Pabeidzot darbu, tās tiek apvienotas ar develop. Testēšana var notikt gan pēc apvienošanas ar develop, gan no pašas šakas, atkarībā no procesa.

Konkrētas pieejas izvēle ir atkarīga no komandas pieņemtās šaku stratēģijas (Gitflow, Trunk-Based Development u.c.) un CI/CD pipeline iestatījumiem. Visbiežāk testēšanas kontūrs automātiski izvieto izmaiņas no develop šakas katrā commita laikā.

CI/CD konfigurācijas piemērs (Jenkins Groovy Script):

// Pārlūks, kas darbojas, kad ir commits `develop` šakā
pipeline {
    agent any
    stages {
        stage('Checkout') {
            steps {
                checkout scm
            }
        }
        stage('Build') {
            steps {
                sh './build.sh' // Programmas būvēšana
            }
        }
        stage('Deploy to Dev Test') {
            when {
                branch 'develop' // Tikai no `develop`
            }
            steps {
                sh './deploy_to_dev_test.sh' // Dēploy uz testēšanas kontūru
            }
        }
        stage('Run Automated Tests') {
            steps {
                // UI/API testu palaišana testēšanas kontūrā
                sh './run_automated_tests.sh'
            }
        }
    }
}

GitLab CI/CD konfigurācijas piemērs:

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

build:
  stage: build
  script:
    - ./build.sh # Programmas būvēšana

deploy_dev_test:
  stage: deploy
  only:
    - develop # Tikai no `develop`
  script:
    - ./deploy_to_dev_test.sh # Dēploy uz testēšanas kontūru

run_automated_tests:
  stage: test
  script:
    - ./run_automated_tests.sh # UI/API testu palaišana
  needs: ["deploy_dev_test"] # Pēc veiksmīgas dēploy

Ja tiek izmantotas feature šakas, pipeline var tikt konfigurēts tā, lai dēployētu pagaidu vidi šīm šakām testēšanai:

GitLab CI/CD ar dinamiskām vidēm:

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

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

deploy_feature_env:
  stage: deploy
  except:
    - develop # Šeit nedrīkst dēployēt `develop`
    - main # Šeit nedrīkst dēployēt `main`
  script:
    - ./deploy_dynamic_env.sh $CI_COMMIT_REF_SLUG # Pagaidu vides dēploy
  environment:
    name: review/$CI_COMMIT_REF_SLUG # Dinamisks vides nosaukums
    url: http://$CI_COMMIT_REF_SLUG.test.example.com # Vides URL
    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

Tādējādi, testēšanas kontūrā visbiežāk tiek izmantota develop šaka, kas nodrošina pastāvīgu jaunāko izmaiņu testēšanu. Atkarībā no procesa, var tikt izmantotas arī feature vai bugfix šakas konkrētiem testiem.

Kuru zaru izmantojat izmaiņu piemērošanai izstrādes testēšanas vidē?