Arpit MohanTL;DR style notes from articles I read today.
Automated continuous deployment at Heroku
- When adding new automation, start small.
- Make it easy to onboard. Configuring pipelines and listing alerts to monitor should be easier than manually deploying.
- If a manual process was working fine apart from speed, let the automated process use the same model.
- Isolate early pipeline stages by team environment to avoid affecting other teams right away.
- Teach deployers to use context the way a human would - scan for open incidents, check whether changes have been merged (or it might use incomplete work).
- Use internal feature flags to separate the deployment of changes and the enabling of features.
Full post here, 8 mins read
Benefits of continuous delivery
- Small, frequent deploys contain less code and hence less risk of introducing bugs. Recovery is easier too.
- Troubleshooting is easier because there is a single change (or just very few) to check and it is fresh in your mind.
- Customers prefer quick access to new features. It ensures quick feedback from customers for every feature which can guide you to your next version.
- You need a DevOps culture where the developer is also the deployer. Automate build and deployment to be quick and easy.
- Set up the system for rolling upgrades, deploying server by server to avoid service interruption.
- Make it easy to revert to an earlier version if there are problems with a new deploy.
Full post here, 5 mins read
Tips and tricks for scalable CI/CD flow
Tips to help you scale up CI/CD flows for big projects if you are using Docker and Kubernetes:
- Define your VCS (version control system) flow, with help from Git Flow or Github Flow.
- When using a complicated manual release process, use tags to trigger production releases.
- Adapt your Git flow for the number of environments you have.
- Set up notification channels to track all CI flow processes.
- Keep Docker images simple. Avoid passing env variables. Use the Run command or let Kubernetes handle this.
- Define a Docker image naming convention - for development and UAT, where there is no rollback, you can use branch names as tags so the previous image is overridden; for production, tag with the release version number.
- Execute database migrations as a separate step outside the Dockerfile.
- Avoid private libraries and submodules.
Full post here, 5 mins read
