Comparative Analysis of CI/CD Strategies and Git Branching Models in Two Projects

Taking advantage of a relaxed weekend afternoon, the author analyzes and compares the CI/CD (continuous integration/continuous delivery) strategy and Git branching model of a recent project (Project A) with a previous one (Project B), aiming to provide insights for developers and operations staff who want to build deployment pipelines or understand Git workflows.

Background

Project A belongs to a large foreign telecom operator and serves as a user self‑service platform. It consists of over thirty independent services, each with its own code repository, AWS EC2 instance, and Jenkins job for automated build and deployment, supporting a migration toward a micro‑service architecture.

The discussion focuses solely on the CI/CD strategy of this project.

Project A CI/CD Strategy

The Jenkins job structure for each service includes two main automated tasks: Build and Deploy . The Build task is triggered by commits to branches (develop, feature, release) and produces an AMI image after running tests. The Deploy task requires manual triggering to select the AMI and adjust configuration before provisioning EC2 instances, ELBs, etc., using Chef. This pattern is replicated across roughly thirty services.

The diagram (shown in the original article) illustrates the job hierarchy, where black circles indicate fully automated steps, circles with a slash indicate manual configuration before triggering, and empty circles indicate manual triggering.

Key characteristics of this approach are:

Branch‑ and environment‑centric: each branch can be built and deployed independently to separate environments (e.g., feature1 → qa‑1, feature2 → qa‑2).

Maintains automation for build and deployment, though some configuration changes are manual.

Automated test duration is kept reasonable by consolidating tests within the build job.

Environment progression is not strictly linear because deployments are manually selected, so a change may only reach a subset of environments.

Project B Strategy and Comparison

Project B uses a more traditional pipeline (Jenkins or GoCD) where build, test, and deployment stages are chained in a single flow. After code commit, the pipeline automatically builds, runs unit/integration/regression tests, and deploys to a Dev environment. Subsequent environments (QA, pre‑prod, prod) require manual triggering but are still automated.

Comparing the two strategies against the three goals of a deployment pipeline (visibility, rapid feedback, automation) yields:

Visibility: Project B’s pipeline is more intuitive and easier for non‑developers to understand, while Project A’s split jobs are less visual.

Feedback: Both provide feedback on success/failure, but Project A’s feedback loop is slower due to longer integration cycles.

Automation: Project B achieves higher automation; Project A still requires manual configuration and triggering.

Project A’s design emphasizes isolation and dependency management, allowing per‑service configuration changes before deployment, which can be advantageous in a large‑scale micro‑service environment.

Git Branching Models

Project A follows the classic Git Flow model with branches: master (production), develop (integration), feature, release, and hotfix. This provides strong isolation and clear responsibilities but can lead to long integration cycles, duplicate testing, and a complex branch hierarchy.

Additionally, story‑card branches are created off feature branches, further increasing granularity.

Project B adopts a simpler model often referred to as GitHub Flow, where all work is based on a single main branch (develop/master) and short‑lived feature branches are merged back after review. This yields a simpler structure, aligns with small‑step commits and continuous integration, but may require feature toggles to prevent unfinished work from affecting releases and offers weaker isolation.

Conclusion

Both strategies have distinct advantages and drawbacks; the choice depends on project size, team preferences, and the need for isolation versus simplicity. Hybrid approaches are possible, such as applying Project B’s pipeline to Project A’s services when appropriate.

Overall, these modern, automated approaches represent a significant improvement over traditional, non‑automated deployment methods.