What is portability? The application or platform you are currently developing needs to work on your machine but also in the production environment where all the users are using it. The measure of Portability is the ability of the application to behave predictably in all environments.
In this article, I talk about portable configuration and using code branching effectively with your team when developing software products. By adding some DORA metrics to your reporting, it's easy to quantify the effect portability has on your overall quality
why do I need to do this?
The reliability of the software increases when it works in production without modification, so this effort starts when developing on your local machine. When developing an application there is going to be a need to build the app locally and deploy it to your production environment for the users to use the app. There could be testing, staging, and other environments along the way. Enabling some good practices for the configuration of the app makes developing and testing a lot easier and reduces the stress of deployment.
Keys to success:
- A new person should be able to pull, run tests, start app with just .local.env, and can hook into secrets in a vault when in dev, staging and production environments
- Keep environment config versions and use the environment to use a specific file.
how do I do this?
The application code shouldn’t change, the configuration of the code is what changes. This configuration is unique to each environment (local, dev, staging, production). Reduce the complexity of moving to production removes barriers and increases velocity
- Collaborative development with PRs
- The sooner the smallest architecture changes are established, the easier the validation in the build process. The maintainability of the codebase is fundamental to portable software
- Configuration of the System.
- By deploying to the integration environment and testing the system, you can gain confidence that the system will work the same way in production
- use env files and keep secrets safe in cloud storage
- Configuration of the product
- Use Feature Flagging to limit access to incomplete functionality
- Align on the product level for releasing the user-facing feature. Release internally first so docs and support know what the customer is getting.
Branches of Code
How to integrate my work with the code from other developer teams? Use Trunk-based development for collaboration and velocity. This process allows integration of PRs and rapid deployment of the outcomes.
What is the trunk? it is the main branch and should match the deployed branch in the production environment. When changes are in the main branch, expect those changes to work immediately in staging and production environments.
- Ensures smaller changes
- features that aren’t ‘ready’, that don’t fulfill the full intention of the feature and don’t fully solve the user problem don’t need to be in a separate branch,
- Use feature flags to only allow users that have the alpha, beta or GA access, but remove them and tie them to the license source of truth for access and usage stats to understand the impact (and usefulness) to the user
- sometimes an alpha version is required to show progress and demoing the functionality through the alpha-beta-GA cycle
- Prevents over-engineering through smaller changes
- Favours rebasing changes on the main branch instead of large merges. This keeps the history cleaner on the main branch and makes rollbacks much easier if needed.
Feature Branches
- building a feature in a separate branch sounds like a good idea, but incurs a lot of maintenance effort when keeping the branch up to date
- frequent updating and merging
- merge conflicts
Release branches
- When a deployment to production is complete, the semver of the release is known. It can ease the transition to trunk-based development to create a Release branch to handle any hotfixes made to the production system between releaseses. This allows small changes in prod so users aren’t blocked by using the product while the large feature branches are merged and validated.
- the same change is applied to the main branch with a test so the main branch has the changes integrated already for the next deploy
More on specific git commands here
https://jseller.blogspot.com/2020/03/source-control-saves-time-and-complexity.html
Automation
Use automation to validate this portability and test the observability at the same time.
- Use a certified CI/CD for package and dependency validation
Use pipelines in bitbucket or github to automatically deploy your main branch to a development server, for larger production deployments there is Harness and other tools that can deploy to many nodes to reduce the complexity of setting up many production instances.
- Run tests appropriate to the environment
- local tests and mock data for local development
- Integration tests and synthetic data for staging
- Production smoke tests to validate
Use an automated test to add a quality step to your deployment scripts. The deployment is finished when it is validated, not just deployedValidate your observability when validating the deployment. This is essential to certify the system is up to date for deprecation or security fixes
Metrics to measure?
Good portability helps velocity and collaboration, but how does it do that? Use DORA metrics to understand how the portability is affecting deployments and rework
- Change Failure Rate
- Deployment frequency
https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance
Conclusion
No matter how careful you are about the portability of the app; things are going to happen when many people are working on the application.
Adding quality through Portable patterns like code branching and automation will go a long way to ironing out the issues before deploying to production
Also see:
https://jseller.blogspot.com/2019/01/feature-definition-with-quality-model.html
https://jseller.blogspot.com/2020/03/packaging-code-for-development-and.html
https://dora.dev/capabilities/trunk-based-development/
No comments:
Post a Comment