Welchen Branch verwenden Sie, um Änderungen in der…

develop oder ein spezialisierter Feature/Bugfix-Branch, der dann in develop zusammengeführt wird.

Optionen:

develop: Hauptentwicklungszweig, in den alle neuen Features und Korrekturen integriert werden. Ideal für kontinuierliche Integration und Tests der neuesten Änderungen.
Feature/Bugfix-Branches: Für größere Features oder dringende Korrekturen können separate Branches verwendet werden. Nach Abschluss werden sie in develop zusammengeführt. Das Testen in der Testumgebung kann sowohl nach dem Merge in develop als auch direkt aus dem Branch erfolgen, abhängig vom Prozess.

Die Wahl der konkreten Vorgehensweise hängt von der im Team verwendeten Branching-Strategie (Gitflow, Trunk-Based Development usw.) und der Konfiguration der CI/CD-Pipelines ab. In den meisten Fällen deployt die Testumgebung automatisch die Änderungen aus dem Branch develop bei jedem Commit.

Beispiel für eine CI/CD-Konfiguration (Jenkins Groovy Script):

// Pipeline, die bei Commit in `develop` ausgelöst wird
pipeline {
    agent any
    stages {
        stage('Checkout') {
            steps {
                checkout scm
            }
        }
        stage('Build') {
            steps {
                sh './build.sh' // Anwendung bauen
            }
        }
        stage('Deploy to Dev Test') {
            when {
                branch 'develop' // Nur aus `develop` deployen
            }
            steps {
                sh './deploy_to_dev_test.sh' // Deployment in Testumgebung
            }
        }
        stage('Run Automated Tests') {
            steps {
                // UI/API-Tests in Testumgebung starten
                sh './run_automated_tests.sh'
            }
        }
    }
}

Beispiel für eine CI/CD-Konfiguration (GitLab CI/CD):

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

build:
  stage: build
  script:
    - ./build.sh # Anwendung bauen

deploy_dev_test:
  stage: deploy
  only:
    - develop # Nur aus `develop` deployen
  script:
    - ./deploy_to_dev_test.sh # Deployment in Testumgebung

run_automated_tests:
  stage: test
  script:
    - ./run_automated_tests.sh # UI/API-Tests starten
  needs: ["deploy_dev_test"] # Nach erfolgreichem Deployment starten

Bei Verwendung von Feature-Branches kann das Pipeline so konfiguriert werden, dass temporäre Umgebungen für Tests dieser Branches bereitgestellt werden:

Beispiel für GitLab CI/CD mit dynamischen Umgebungen:

# 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 # Deployment einer temporären Umgebung
  environment:
    name: review/$CI_COMMIT_REF_SLUG # Dynamischer Name der Umgebung
    url: http://$CI_COMMIT_REF_SLUG.test.example.com # URL der Umgebung
    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

Auf diese Weise wird für die Entwicklungsumgebung meist der Branch develop verwendet, der eine kontinuierliche Testung der neuesten Änderungen gewährleistet. Abhängig vom Prozess können auch Feature- oder Bugfix-Branches für gezielte Tests genutzt werden.

Welchen Branch verwenden Sie, um Änderungen in der Testentwicklungsumgebung anzuwenden?