How did you implement CI/CD logic using git flow?

Using Git Flow, CI/CD logic can be structured as follows:

• feature branches: When creating a new feature or making changes, the developer works in a separate feature branch branched off from develop. Each change in this branch can trigger a minimal set of checks (static analysis, linting).
• pull request (PR) / merge request (MR): After completing work on a feature, a PR/MR is created to merge the feature branch into develop. This triggers a full CI pipeline:
  • project build
  • run all tests (unit, integration, acceptance)
  • code standards check (linting, formatting)
  • security analysis of the code
  • artifact build (e.g., Docker images)
• develop branch: Merging into develop occurs only after all CI checks pass and code review is completed. Each merge into develop triggers the CD part of the pipeline:
  • deploying artifacts to the development environment
  • conducting automated UI/E2E tests on the deployed version.
• release branches: To prepare for a release, a release branch is created from develop. Final stabilization work and bug fixes are performed on this branch. The pipeline for release branches may include:
  • CI checks (similar to develop).
  • building release artifacts.
  • deploying to the testing/staging environment for manual testing and acceptance.
• main / master branch: After stabilization, the release branch is merged into main (or master) and tagged with the version number. Merging into main triggers:
  • building production artifacts.
  • deploying to the production environment.
• hotfix branches: For urgent fixes in production, a hotfix branch is created from main. The pipeline for hotfix branches is similar to the release pipeline:
  • CI checks.
  • hotfix artifact build.
  • deploying to staging for verification.
  • deploying to production after successful verification. The hotfix branch is also merged back into develop to synchronize changes.

Example structure of pipelines in Git Flow:

Git Flow Branch	CI/CD Trigger	CI Tasks	CD Tasks	Deployment Environment
feature/*	Push to branch	Linting, static analysis	None (optional, on test environment for developer)	None
feature/*	PR/MR to develop	Build, tests (unit, integration), security analysis, artifact build	None	None
develop	Merge PR/MR	-	Deployment to Dev, UI/E2E tests	Development
release/*	Branch creation, Push	Build, tests, security analysis, release artifact build	Deployment to Staging, manual testing, acceptance	Staging
main	Merge release/*	Build production artifacts	Deployment to Production	Production
hotfix/*	Branch creation, Push	Build, tests, security analysis, hotfix artifact build	Deployment to Staging, manual testing, acceptance, Deployment to Production	Staging/Production

Using tags in Git Flow on the main (or master) branch triggers the final CD stage – deployment to Production.

# Example pipeline in GitLab CI/CD for the main branch
build_deploy_prod:
  only:
    - main@<your_repo_path> # Trigger on push to main
    - tags # Trigger on tag creation
  stage: deploy_prod
  script:
    - echo "Building production artifacts..."
    # Commands for building the production version
    - echo "Deploying to production..."
    # Commands for deploying to production
  environment:
    name: production
    url: https://<production_env_address>
  when: manual # Or on_success, depending on the process