I have talked to people who work in companies that take weeks or event months to deliver a new release of their software, that is usually means that that release will come with a lot of features, bug fixes and is very likely to have problems. Also, I have seen some companies that the employees have to manually execute tests and deploy the new release to production from their own machines, that takes a lot of time and is very error-prone.
How do we solve all of those problems?
We improve the process, by automating it all! With an automated process, we can assure compliance, agility and overall a more secure environment. Combine that with smaller releases containing atomic changes and you have a continuous integration / continuous deployment (CI/CD) system!
How does it work?
In a CI/CD environment we have a cycle of plan, develop, test, build, deploy with the last 3 automated and isolated in a isolated environment, making it so that the developer does not need to have access to the production environment and will never forget to run tests or any other process they need to check.
That means, CI/CD ensures:
- New features / bug fixes are released faster to production
- Tests, lint checks, compliance checks are never forgot to run.
- Smaller releases that are easier to debug, since they only carry atomic changes
Releases
To make a good release, as said before, we have to include only atomic changes, i.e. related, small changes. But that’s not all, a great release should also have a good name and description, for that I encourage the usage of semantic messages, defining a pattern that helps you understand the context. A pattern that works for me is <operation> (<scope>): message, for example: feature(handlers): update user , in that message I know that a new feature was added to the handlers that is related to updating users.
Pipeline configuration is also code
It’s really easy to get caught up in writing confusing pipeline configurations. All those good practices for organizing and writing good, reusable code should be taken into account wile writing pipeline configurations.
Some tips for that:
- Always have naming conventions for pipelines across all your projects
- If your runner has support for that, write multiple files, grouping what is related
- Make good use of your time, run all tasks only if needed using trigger rules
Using pipelines with creativity
We can also use pipelines for other purposes other than just test, build and deploy. Here are some examples of usages I have on my projects to inspire you:
- Generate automated docs and open PRs with the changes
- Open issues on projects with dependency
- Send notifications about deploys
- Announce releases on social media
Conclusion
Automate everything you can! Make your deployment process very secure, agile and simple. And always try to improve.