Releasing product is one of the critical phase of software development life cycle, so much brainstorming will go in to design versioning and release strategy for a product. In olden days, it was all different, applications were monolithic, build and release management teams used to build this, entirely as a package (.WAR or .EAR files) by creating one version and putting it in artifact repository, triggering a process to deploy package in application servers. Versioning is pretty straight forward because it is monolithic and treated as one application.
Now things are changed, considering complexity and inflexibility of monolithic application, people has opted to build application as set of smaller and interconnected services called microservices. In effect of this, versioning and releasing of individual microservices and for overall application became complex. There are no straight forward principles which solves problem, it entirely depends on various factors like branching strategy for microservices, source code repository management (multi repository vs mono repository), build release tools to deploy and platform on which its deployed.
We as a team, based on our project requirements decided to use mono repository strategy for our application code and one fixed branch strategy for individual microservice. Master branch holds production ready and consolidated microservices code where each service keeps their code in one dedicated folder. kubernetes deployment yamls and cofigurations maintained in another repository. Considering above all, we have designed and implemented Tagging strategy for our microservices, which helps us to release and version our product efficiently.
Following flow chart shows sequence of events happens during release:
Basically an orchestrator called Release tagging jenkins job, monitors any merges happens to master on microservice repo via hook job and triggers respective ms builds, prepares versions of all microservices based on latest successful builds, applies to kubernetes cluster and watches for changes to take place. Based on its current build numbers, it forms a release tag and updates to source code repository and deployments repository, triggers test jobs and updates test case status back to tag release release notes process.
Advantages:
GitTagging:
Kubernetes Deployment Revisions:
Now things are changed, considering complexity and inflexibility of monolithic application, people has opted to build application as set of smaller and interconnected services called microservices. In effect of this, versioning and releasing of individual microservices and for overall application became complex. There are no straight forward principles which solves problem, it entirely depends on various factors like branching strategy for microservices, source code repository management (multi repository vs mono repository), build release tools to deploy and platform on which its deployed.
We as a team, based on our project requirements decided to use mono repository strategy for our application code and one fixed branch strategy for individual microservice. Master branch holds production ready and consolidated microservices code where each service keeps their code in one dedicated folder. kubernetes deployment yamls and cofigurations maintained in another repository. Considering above all, we have designed and implemented Tagging strategy for our microservices, which helps us to release and version our product efficiently.
Following flow chart shows sequence of events happens during release:
Basically an orchestrator called Release tagging jenkins job, monitors any merges happens to master on microservice repo via hook job and triggers respective ms builds, prepares versions of all microservices based on latest successful builds, applies to kubernetes cluster and watches for changes to take place. Based on its current build numbers, it forms a release tag and updates to source code repository and deployments repository, triggers test jobs and updates test case status back to tag release release notes process.
Advantages:
- Single release tag is operated across all the stages
- Using release tag, it is easy to back track from artifact to its source code hash. For operations teams, it is lot easier to read revisions for deployments via release tags (release tag updated to kubernetes change cause after each deployment). We can check by using this command kubectl rollout history deploy/deploymentName
- Deployments becomes hassle free using release tag on various production environments
- Rolling update and rollback is quite easy based on tags
Kubernetes Deployment Revisions:
Comments
Post a Comment