[Documentation] Release and Deployment Strategy

[TanmoySG]

A Release and Deploy Strategy is an essential part of Software Delivery Workflow. Not all Commits need to make it to deployment or release. A versioning system is also a cornerstone of this workflow. Hence a strategic approach is required to keep commits and deployment workflows separate. Currently, on a commit to the deploy branch triggers the deployment to Azure which is fine till a separate feature branch exists, but maintaining separate feature branches get tougher with project growing, hence thus Workflow too needs to be triggered only by specific actions like a version tagging or release.

There are three deployments that are to be put into this strategy -

• Automated GitHub Releases on Git Version Tagging
• Automated Dockerization and Deployment to GitHub Packages for Containers
• Deployment to Azure (this will be deprecated/torndown Soon)

[Checkpoints]

• [x] Plan out a deployment strategy
• [x] Integrate GitHub Release, Publishing Docker Container to GitHub Package Registry
• [x] Integrate Azure Deployment - Replace Existing Workflow
• [x] Create Workflows using GitHub Actions
• [x] Test Strategies - Compare and Decide
• [x] Publish v0.1.0-alpha , First Release with the Workflow.

[Issues]

• [x] #81
• [x] #82

[JFYI]

Versioning

A proper versioning system that should be used in this project is

Major.Minor.Patch-target

In the Above

• Major - Major Feature Additions, Breaking API Changes and other Major Changes that can effect the dependant systems.
• Minor - Minor Feature Additions, Backward Compatible, Usage Experience Enhancements and Minor Changes.
• Patch - Bug Fixes, Backward Compatible and Enhancement Fixes and Changes.
• target - Build Targets (OS Specific/OS Version Specific/Architecture Specific Targets) or pre-releases (beta/alpha) or audience/user Targets (general/Pro/internal/etc.)

Refer to semver.org or versioning section in notes

Adopted Strategy

Strategy B, triggers builds/workflows only if the version tagged and committed is a Major or Minor Update as well as Patch updates - so that both Feature-Ready/Feature-full releases and Bug Fixes are published to the artefacts.

On the other hand this strategy may also lead to frequent adoption changes on the user end.

Strategy B

[TanmoySG]

Strategy A

There are two Artefact Build Workflows required

• Release Artefacts
• Containerization Artefact

And a Deployment to Azure Worflow, that will be torndown soon.

Apart from building these artefacts, they are required to be published to GitHub Package Registry and GitHub Releases as well.

There is a requirement for an Automated Workflow - using GitHub Actions - for building and Publishing these. These workflows are to triggered only on specific and special commits like version tagging using git tag. Not all commits or even versioning should trigger these.

Plan and Observations

This, Strategy A, triggers builds/workflows only if the version tagged and committed is a Major or Minor Update - so that only Feature-Ready/Feature-full releases are published.

On the other hand this strategy may also lead to Bug Fixes and Enhancements to be skipped for a long time until a Minor or Major Release Candidate is not Ready.

[TanmoySG]

Strategy B

There are two Artefact Build Workflows required

• Release Artefacts
• Containerization Artefact

And a Deployment to Azure Worflow, that will be torndown soon.

Apart from building these artefacts, they are required to be published to GitHub Package Registry and GitHub Releases as well.

There is a requirement for an Automated Workflow - using GitHub Actions - for building and Publishing these. These workflows are to triggered only on specific and special commits like version tagging using git tag. Not all commits or even versioning should trigger these.

Plan and Observations

This, Strategy B, triggers builds/workflows only if the version tagged and committed is a Major or Minor Update as well as Patch updates - so that both Feature-Ready/Feature-full releases and Bug Fixes are published to the artefacts.

On the other hand this strategy may also lead to frequent adoption changes on the user end.

[TanmoySG]

Updates

Currently using dockerize-flask-test repo to test the Strategy in Action.

[TanmoySG]

Creating a Tag using git

To create a Tag use the git tag command as,

git tag <tag-name>

The tag-name can be the version. You may also create an "annotated tag" using -a flag and a tagging message following the -m flag.

git tag -a v1.4 -m "my version 1.4"

List the tags

git tag

Pushing tags to GitHub or Remote Origin

Push the Tags to remote origin/repo

git push --tags

Learn More at git-scm.com.

[TanmoySG]

How to - Deployment using Git

Currently there are 3 Branches being maintained

• main
• deploy - for Azure Deployment Pipelines
• dev - for development

Code changes are made in the dev branch and merged to main - either periodically to sync code or to sync feature-complete code to main.

Framework to Commit, Merge and Tag Code

• All Changes to code, work on new features, bug fixes are to be done in separate branches, preferably dev.
• The code changes are merged from development branches to main either periodically or on feature maturation.
• Commit Changes to the dev branch, raise a Pull Request, review changes, test changes, merge the PR to main.
• Release Candidates/Deploy-ready Code are to be published only from the main branch.

When the Code is tested, and fit for Release

• In the Editor (Codespaces/VS Code) move from the dev branch to the main branch using git checkout.

  git checkout main

• From the main branch, tag the code using git tag. Use the main branch-name following the tag name so as to ensure tag points to the latest commit on the main branch and hence the tag refers to production ready code on main branch.

  git tag v1.2.34-alpha main

• Sync the tags to remote (GitHub)

  git push --tags

  This should trigger the Deployment Workflows and create a Release and a Container is Published.

Note

• Tags are to be added only from the main branch.
• A Release Candidate must be tagged from the main branch before making any commits to other branches. The latest commit on Main Branch should be tagged and only then should any changes be committed to other branches.
• Not all Merge needs to be followed by tagging.
• Only Tested and Stable Release candidates should be tagged.
• Versions should be according to the versioning guide (above).

[TanmoySG]

Working with Git Tags

Git tags point to the HEAD (latest commit) in the git tree, when no branch is specified. Hence if a tag is created it points to the latest commit (HEAD) in the tree irrespective of the branch.

git tag v1.2.3

To Specify the Target Branch use the branch name in the git tag command

git tag v1.2.3 branch_name

Now the version v1.2.3 will point to the latest commit in the branch specified instead of the HEAD.

Here's a detailed working of git tags on stackoverflow.

[TanmoySG]

Testing Workflows

• Added Release Workflow using GitHub Action [ Actions File - release-on-github.yml ]
• Added Containerize and Publish Workflow using GitHub Action [ Actions File - containerize-and-publish.yml ]
• Added a tag v0.0.1-test for testing purposes.
• 0.0.1-test Release - tag/v0.0.1-test
• 0.0.1-test Containerized and Published - GitHub Docker Registry

[TanmoySG]

Published v0.1.1-alpha!

Published tag v0.1.0-alpha of wIP.

• Release Workflow published the v0.1.0-alpha build
• Container Published on GitHub Package Registry

[TanmoySG]

How is the Code Structured ?