რისი დარგი გამოიყენეთ ცვლილებების განსახორციელებლად განვითარების ტესტის გარემოში?

develop ან სპეციალიზებული ფიჩის/ბაგის ბრენჩი, რომელიც შემდეგ მერჯება develop-ში.

ვარიანტები:

• develop: ძირითადი განვითარების ბრენჩი, სადაც ინტეგრირებულია ყველა ახალი ფუნქცია და გამოსწორება. იდეალურია უწყვეტი ინტეგრაციისა და ბოლო ცვლილებების ტესტირებისათვის.
• Feature/Bugfix ბრენჩები: დიდი ფუნქციებისთვის ან სასწრაფო გამოსწორებებისთვის შეიძლება გამოყენებულ იქნას ცალკეული ბრენჩები. დასრულების შემდეგ, ისინი მერჯებიან develop-ში. ტესტირება შეიძლება მოხდეს როგორც develop-ში მერჯვის შემდეგ, ასევე ბრენჩიდან, პროცესზე დამოკიდებული.

საკუთარი მიდგომის არჩევა დამოკიდებულია გუნდში მიღებულ ბრენჩინგის სტრატეგიაზე (Gitflow, Trunk-Based Development და ა.შ.) და CI/CD პაიპლაინების კონფიგურაციაზე. უმეტეს შემთხვევაში, ტესტის კონტური ავტომატურად დეპლოიტებს ცვლილებებს develop-დან ყოველ კომიტზე.

CI/CD კონფიგურაციის მაგალითი (Jenkins Groovy Script):

// პაიპლაინი, რომელიც მუშაობს `develop`-ში კომიტის დროს
pipeline {
    agent any
    stages {
        stage('Checkout') {
            steps {
                checkout scm
            }
        }
        stage('Build') {
            steps {
                sh './build.sh' // აპლიკაციის მშენებლობა
            }
        }
        stage('Deploy to Dev Test') {
            when {
                branch 'develop' // მხოლოდ `develop`-დან დიპლოი
            }
            steps {
                sh './deploy_to_dev_test.sh' // ტესტის კონტრზე დიპლოი
            }
        }
        stage('Run Automated Tests') {
            steps {
                // UI/API ტესტების გაშვება ტესტის კონტრზე
                sh './run_automated_tests.sh'
            }
        }
    }
}

GitLab CI/CD კონფიგურაციის მაგალითი:

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

build:
  stage: build
  script:
    - ./build.sh # აპლიკაციის მშენებლობა

deploy_dev_test:
  stage: deploy
  only:
    - develop # მხოლოდ `develop`-დან დიპლოი
  script:
    - ./deploy_to_dev_test.sh # ტესტის კონტრზე დიპლოი

run_automated_tests:
  stage: test
  script:
    - ./run_automated_tests.sh # UI/API ტესტების გაშვება
  needs: ["deploy_dev_test"] # წარმატებული დიპლოის შემდეგ

თუ გამოიყენება feature-ბრენჩები, პაიპლაინი შეიძლება იყოს კონფიგურირებული ისე, რომ დიპლოიტოს დროებითი გარემოები ამ ბრენჩებისთვის:

GitLab CI/CD დინამიური გარემოებით:

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

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

deploy_feature_env:
  stage: deploy
  except:
    - develop # აქ არ დიპლოი `develop`-დან
    - main # აქ არ დიპლოი `main`-დან
  script:
    - ./deploy_dynamic_env.sh $CI_COMMIT_REF_SLUG # დროებითი გარემოს დიპლოი
  environment:
    name: review/$CI_COMMIT_REF_SLUG # დინამიური გარემოს სახელი
    url: http://$CI_COMMIT_REF_SLUG.test.example.com # გარემოს 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

ამრიგად, განვითარების ტესტის კონტურისთვის უმეტესად გამოიყენება develop ბრენჩი, რომელიც უზრუნველყოფს ბოლო ცვლილებების მუდმივ ტესტირებას. პროცესზე დამოკიდებული, ასევე შეიძლება გამოყენებულ იქნას feature ან bugfix ბრენჩები კონკრეტული ტესტირებისათვის.