GitOps branching and deploy strategy

[lindjacob]

Imagine we have a GitOps branching and deploy strategy that doesn't rely on Pull Requests, but simply rely and branches and tags. It goes like this.

👉 All development must be done on development branches - named after the issue it solves

gitGraph
    commit id: "Initial"
    branch issue-1
    checkout issue-1
    commit id: "devcontainer"
    commit id: "gitconfig"

👉 When a development on a branch is done it's marked with a READY tag which triggers a GitHub workflow that will:

• rebase to main - if new commits has arrived.
• Run a unit test
• Deliver to main only if unit test is successful

gitGraph
    commit id: "Initial"
    branch issue-1
    checkout issue-1
    commit id: "devcontainer"
    checkout main
    commit id: "Close #2"
    checkout issue-1
    commit id: "gitconfig" tag: "READY"
    merge main id: "rebase" type: NORMAL
    checkout main
    merge issue-1 id: "Close #1"

👉 When a new commit is added to main it triggers a GitHub workflow that will:

• Deploy to stage environment
• Run an automated functional test

gitGraph
    commit id: "Initial"
    commit id: "Close #2"
    commit id: "Close #1" type: HIGHLIGHT

👉 When a commit on main it tagged with a SemVer[^semver] tag it triggers a GitHub workflow that will:

• Deploy to prod environment
• Run an automated smoke test

[^semver]: Semantic Versioning is s three-level integer version tag, the levels indicate major, minor and patch levels .

gitGraph
    commit id: "Initial"
    commit id: "Close #2"
    commit id: "Close #1" tag: "1.0.0"

---

• How do you like this strategy?
• Create a GitHub Workflow - a .github/workflows/*.yml file - that implements this behaviour. Not the actual tests and deploys but the workflow that would trigger them.

[lindjacob]

Discussion on the strategy

Positives

1. Automation and Efficiency:

   • The use of tags and automated workflows reduces manual tasks and avoids human mistakes.
   • Automation ensures that all necessary steps (e.g., rebasing, testing, deployment) are consistently performed .

2. Continuous Integration and Continuous Deployment (CI/CD):

   • Automated testing (unit, functional, and smoke tests) ensures that only verified code reaches production.

3. Branch Isolation:

   • Development branches for each issue isolate changes, reducing the risk of conflicts and making it easier to manage multiple parallel developments.

4. Deployment Control:

   • Using SemVer tags for production deployments allows for controlled releases, making it easy to track and manage different versions of the application.

Negatives

1. Lack of Issue Tracking:

   • Since workflow strategy does not use issues, it can lead to a lack of visibility and traceability of work items, which makes it challenging to track the progress, context, and discussion around specific changes.

2. Efficiency:

   • Each minor edit or syntax error requires a new tag, leading to a workflow slowdown.

3. Rebasing Risks:

   • Automated rebasing can introduce complexities, especially if there are significant conflicts that require manual resolution.
   • Force-pushing after rebasing can potentially overwrite changes if not managed carefully.

4. Testing Coverage:

   • The strategy assumes that tests are comprehensive and reliable. Inadequate test coverage can lead to issues slipping through the pipeline.

5. Resource Intensity:

   • Frequent testing can be resource-intensive, potentially leading to higher infrastructure costs.

6. Complexity for New Developers:

   • New developers may find the tagging and branching strategy complex, leading to a steeper learning curve.

Conclusion

Given my thoughts on the positives/negatives I would probably prefer a CI/CD workflow that uses issues and human oversight for the rebasing process.