-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Documentation] Release and Deployment Strategy #79
Comments
Strategy AThere are two Artefact Build Workflows required
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 Plan and Observations This, 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. |
Strategy BThere are two Artefact Build Workflows required
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 Plan and Observations This, On the other hand this strategy may also lead to frequent adoption changes on the user end. |
UpdatesCurrently using dockerize-flask-test repo to test the Strategy in Action. |
Creating a Tag using
|
How to - Deployment using GitCurrently there are 3 Branches being maintained
Code changes are made in the Framework to Commit, Merge and Tag Code
When the Code is tested, and fit for Release
This should trigger the Deployment Workflows and create a Release and a Container is Published. Note
|
Working with Git TagsGit 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.
To Specify the Target Branch use the branch name in the git tag command
Now the version v1.2.3 will point to the latest commit in the branch specified instead of the HEAD. |
Testing Workflows
|
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 -
[Checkpoints]
v0.1.0-alpha
, First Release with the Workflow.[Issues]
[JFYI]
Versioning
A proper versioning system that should be used in this project is
In the Above
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
The text was updated successfully, but these errors were encountered: