Mastering the Microservices Lifecycle: A Deep Dive from Code Creation to Seamless Deployment in Enterprise SaaS product development
An architecture flow diagram for an Enterprise SaaS app microservice, illustrating the comprehensive journey from writing code to deployment and release, involves multiple stages. Below is a high-level description, and you can find a visual representation of these steps in a flow diagram from deployment to release. Here is a flow diagram for one microservice, and a similar setup can be created for each microservice.
I was involved in setting up this flow for a SaaS product app using the following tech stack, and the architecture is robust, functioning effectively for enterprise applications.
Tech Stack
Code Repository : GitHub
CI/CD: Azure DevOps (Supports approval, release pipelines) & Jenkins
Container Registry: Google Artifact Registry
Deployment: Google Kubernetes Cluster
Environment:
Staging :
Daily development changes are published in staging Kubernetes (K8s) cluster.
Pre-production:
During release time, there is a stage before moving to production where all release changes are published, and a sanity test is performed. This environment helps avoid breaking issues in production. Although the pre-production and production Kubernetes (K8s) clusters are different, the pre-production cluster configuration is exactly the same as production.It is better to maintain separate Kubernetes (K8s) clusters and environments for Staging, Pre-production, and Production to ensure better isolation for each stage.
Production:
After a sanity test, the same pre-production Docker image is used in the production cluster. It’s important to note that the production Kubernetes (K8s) cluster differs from the pre-production cluster.
Pro-Tip:
Configuration settings, such as the database connection string, should not be maintained in the code. Instead, they can be stored in Kubernetes secrets or config maps. This ensures that there are no changes in the source code from Staging to Development to Production, thus avoiding the need for manual code merging. Feature flags can also be employed to deactivate certain features if they differ from the staging environment.
Staging Stage
Development:
Developers write code for the microservice by creating a branch from the development source code and utilizing version control systems (e.g., Git) to manage changes.
Continuous Integration (CI):
After completion, the developer creates a merge request from the feature branch to the development branch. Subsequently, the code is integrated into a shared repository, and automated CI processes (e.g., Jenkins, GitHub Actions) run tests to ensure the stability of the codebase.
Code Review:
Code undergoes peer review for quality, security, and adherence to coding standards. After review code is merged to development source. For approval, it is recommended to have multiple persons review the code. GitHub provides an option to set multiple approvals.
Continuous Deployment Pipeline:
After code approval and merging, an Azure DevOps pipeline is automatically triggered to build the Docker image.
Artifact Generation:
Successful CI builds generate artifacts, such as Docker images or compiled binaries.
Artifact Repository:
Container images and other artifacts are stored in a secure and versioned artifact repository (Google Artifact Registry).
Deployment to Staging:
The microservice is deployed to a staging environment for further testing and validation.
Testing:
Comprehensive manual testing, and possibly performance and security tests, is conducted in the staging environment. Users or stakeholders conduct UAT to ensure the functionality aligns with business requirements.
Pre-production Stage:
After the codes are tested during release time, this stage becomes active. A merge request is created from the Development branch to the master branch, and the manager reviews the final PR, merging the changes into the Master branch.
Pre-production Azure DevOps Pipeline:
Once code is merged into the master branch, the Azure DevOps production pipeline is automatically triggered, taking advantage of the available option in Azure DevOps for such triggers. The pipeline generates a Docker image, similar to staging, and publishes it to the production artifact registry.
A snapshot depicting the Azure DevOps Pre-Production and Production Stage Release Deployment Pipeline.
Approval Workflow:
A manager or designated authority approves the microservice for promotion to the pre-production environment.
Deployment to Pre-production:
The approved microservice is deployed to the pre-production environment for final validation, and there is no redeployment after pre-production. Only the Docker image version number is refreshed in the production cluster’s app YAML file using the Azure DevOps pre-production pipeline.
Approval for Production:
After successful sanity testing in the pre-production environment, the manager approves the microservice for deployment to production. Importantly, there is no additional build pipeline; the same Docker image from the pre-production environment is promoted to production, and this pipeline can be easily built using Azure DevOps.
Deployment to Production:
The microservice is released to the production environment.
That’s it! A robust automated workflow for the enterprise app, seamlessly guiding the process from code development to the final deployment.
Conclusion:
These steps in a visual flowchart can help illustrate the end-to-end process of taking code from development through various testing stages to deployment and release in a microservices architecture for an Enterprise SaaS app.
Additional Reference:
Gitflow works well for large enterprise SaaS products much better. I have been practicing Gitflow for several years. It just helps in releasing and maintaining the product codebase with ease.
https://www.gitkraken.com/blog/gitflow
