Quale ramo utilizzi per applicare le modifiche…

develop o un ramo specializzato di funzionalità/bug, che viene poi unito in develop.

Opzioni:

develop: Ramo principale di sviluppo, in cui vengono integrate tutte le nuove funzionalità e correzioni. Ideale per integrazione continua e test delle ultime modifiche.
Rami di Feature/Bugfix: Per grandi funzionalità o correzioni urgenti, possono essere usati rami separati. Dopo il completamento, vengono uniti in develop. I test in ambiente di test possono essere eseguiti sia dopo il merge in develop che direttamente dal ramo, a seconda del processo.

La scelta della strategia specifica dipende dalla strategia di branching adottata dal team (Gitflow, Trunk-Based Development, ecc.) e dalla configurazione dei pipeline CI/CD. Nella maggior parte dei casi, l'ambiente di test distribuisce automaticamente le modifiche dal ramo develop ad ogni commit.

Esempio di configurazione CI/CD (Jenkins Groovy Script):

// Pipeline attivata da commit nel ramo develop
pipeline {
    agent any
    stages {
        stage('Checkout') {
            steps {
                checkout scm
            }
        }
        stage('Build') {
            steps {
                sh './build.sh' // Costruzione dell'applicazione
            }
        }
        stage('Deploy to Dev Test') {
            when {
                branch 'develop' // Solo da develop
            }
            steps {
                sh './deploy_to_dev_test.sh' // Deploy in ambiente di test
            }
        }
        stage('Run Automated Tests') {
            steps {
                // Esecuzione di test UI/API in ambiente di test
                sh './run_automated_tests.sh'
            }
        }
    }
}

Esempio di configurazione CI/CD (GitLab CI/CD):

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

build:
  stage: build
  script:
    - ./build.sh # Costruzione dell'applicazione

deploy_dev_test:
  stage: deploy
  only:
    - develop # Solo da develop
  script:
    - ./deploy_to_dev_test.sh # Deploy in ambiente di test

run_automated_tests:
  stage: test
  script:
    - ./run_automated_tests.sh # Esecuzione di test UI/API
  needs: ["deploy_dev_test"] # Esegue dopo il deploy

Nel caso di utilizzo di rami di feature, il pipeline può essere configurato per distribuire ambienti temporanei per testare questi rami:

Esempio di GitLab CI/CD con ambienti dinamici:

# 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 di ambiente temporaneo
  environment:
    name: review/$CI_COMMIT_REF_SLUG # Nome dinamico dell'ambiente
    url: http://$CI_COMMIT_REF_SLUG.test.example.com # URL dell'ambiente
    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

In questo modo, per l'ambiente di sviluppo si utilizza generalmente il ramo develop, che garantisce il test continuo delle ultime modifiche. A seconda del processo, possono essere usati anche rami di feature o bugfix per test mirati.

Quale ramo utilizzi per applicare le modifiche nell'ambiente di test di sviluppo?