Welke tak gebruik je om wijzigingen toe te passen in…

develop of een gespecialiseerde feature/bug branch, die vervolgens wordt gemerged in develop.

Opties:

develop: Hoofdtak van ontwikkeling, waarin alle nieuwe functies en correcties worden geïntegreerd. Ideaal voor continue integratie en testen van de laatste wijzigingen.
Feature/Bugfix branches: Voor grote functies of dringende correcties kunnen aparte branches worden gebruikt. Na voltooiing worden ze samengevoegd met develop. Testen op de testomgeving kan zowel na de merge in develop als rechtstreeks vanuit de branch, afhankelijk van het proces.

De keuze voor de specifieke aanpak hangt af van de door het team gebruikte branching-strategie (Gitflow, Trunk-Based Development, etc.) en de configuratie van CI/CD pipelines. In de meeste gevallen deployt de testomgeving automatisch de wijzigingen uit de develop branch bij elke commit.

Voorbeeld van CI/CD-configuratie (Jenkins Groovy Script):

// Pipeline die wordt geactiveerd bij een commit in de `develop` branch
pipeline {
    agent any
    stages {
        stage('Checkout') {
            steps {
                checkout scm
            }
        }
        stage('Build') {
            steps {
                sh './build.sh' // Applicatie bouwen
            }
        }
        stage('Deploy to Dev Test') {
            when {
                branch 'develop' // Alleen vanaf develop
            }
            steps {
                sh './deploy_to_dev_test.sh' // Deploy naar testomgeving
            }
        }
        stage('Run Automated Tests') {
            steps {
                // UI/API tests uitvoeren op testomgeving
                sh './run_automated_tests.sh'
            }
        }
    }
}

Voorbeeld van CI/CD-configuratie (GitLab CI/CD):

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

build:
  stage: build
  script:
    - ./build.sh # Applicatie bouwen

deploy_dev_test:
  stage: deploy
  only:
    - develop # Alleen vanaf develop
  script:
    - ./deploy_to_dev_test.sh # Deploy naar testomgeving

run_automated_tests:
  stage: test
  script:
    - ./run_automated_tests.sh # UI/API tests uitvoeren
  needs: ["deploy_dev_test"] # Na succesvolle deployment

In het geval van feature branches kan de pipeline worden geconfigureerd om tijdelijke omgevingen te deployen voor het testen van die branches:

Voorbeeld van GitLab CI/CD met dynamische omgevingen:

# 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 # Deploy van tijdelijke omgeving
  environment:
    name: review/$CI_COMMIT_REF_SLUG # Dynamische naam van de omgeving
    url: http://$CI_COMMIT_REF_SLUG.test.example.com # URL van de omgeving
    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

Op deze manier wordt voor de ontwikkelomgeving meestal de develop branch gebruikt, die continue testen van de laatste wijzigingen garandeert. Afhankelijk van het proces kunnen ook feature- of bugfix-branches worden gebruikt voor gerichte tests.

Welke tak gebruik je om wijzigingen toe te passen in de testontwikkelomgeving?