This content originally appeared on DEV Community and was authored by Ben Brazier
Continuous delivery is hard. There is no simple way to learn all of the moving parts required to automate packaging, configuring, deploying, testing and releasing code. It isn’t something you can implement in a week and it requires time and effort to work towards.
If every step in the process is done with a different tool, by a different team, or in a different location, then it can feel impossible to continuously deliver on a daily basis. But it isn’t. You can continuously deliver code without needing to know 15 different tools and talk to 5 different teams within your organisation.
What is Continuous Delivery?
Continuous delivery is about having the ability to go from source code to production quickly and in a fully automated process. It enables small, frequent updates that minimise risk and maximise feedback. The benefits are generally well understood across the industry but the implementations vary. Some teams deliver changes to production every few minutes, while others can take weeks or months to release new code.
It should be possible for most teams to deliver changes daily, but in order to understand why we need to know what issues can get in the way.
Why is it so Difficult?
Dev and Ops culture separation can be a strong contributor to how well teams can continuously deliver. A significant factor in the culture of a team is resourcing.
It is easy to find developers who want to write code on their laptop but hard to find developers who want to manage infrastructure.
It is easy to find operations people who want to manage infrastructure but hard to find operations people who want to write code.
It is especially hard to find team members that want to write, deploy, test, release and support services when a large part of the industry prefers to split these tasks into different teams and even different sections of an organisation.
Tools and vendors are a dime a dozen. For any part of the continuous delivery process, you can find a handful of tools and vendors trying to get you to use them. This makes it extremely easy to pick up and add complexity to the stack, which simultaneously raises the bar of knowledge required and often hides the underlying fundamentals of how software is delivered.
Even when implementing a tool for each step in continuous delivery it is common to find gaps and integration points that aren’t supported and require an understanding of the whole stack to resolve. This is why we should focus on a minimal stack and treat every extra tool or vendor as a debt in both the technical and business sense.
Guidance and training is easy to find when it comes to using one of the vendor provided tools, but is hard to find if you just want to understand the fundamentals. But where and how can we learn the fundamentals?
I have been asked a lot in my work to provide reference for how to implement continuous delivery and in my experience there is a lot of theory available but not much implementation. I believe this is a problem that needs to be resolved in the industry right now, which is what I am aiming to achieve.
How Can We Make it Easier?
When it comes to complex problems we need to think long and hard about our options. In the words of Kent Beck, “make the change easy, then make the easy change”. But how do we make the change easy?
Kent Beck@kentbeck
for each desired change, make the change easy (warning: this may be hard), then make the easy change23:07 PM - 25 Sep 2012
Firstly, we must reduce the number of different tools we use and focus our effort on a few key solutions. The more different tools you use, the more knowledge is split up and harder to share.
Tools used across the industry range from code, to DSLs, to cli tools, and more . However, the one thing that we can always rely on is code. Instead of using declarative languages or cli tools we should focus our efforts on code and writing re-usable packages that can be integrated with other tasks. There is no good reason why we can’t package, configure, deploy, test and release code within a single programming language after getting it’s dependencies.
Secondly, we can invest in understanding the implementation. Instead of learning many different tools we can focus on the fundamentals of both the steps required and automation in general.
This is significantly harder initially but results in far better long term goals because tools come and go but understanding is retained.
Thirdly, we need to iterate on your implementation. No matter how simple the system or how much knowledge you have there is no way to improve without iteration because each environment is different. Each change we make may or may not improve things, and the only way to know is to try.
Summary
Continuous delivery is hard, but it doesn’t have to be. By simplifying what is required, focusing on our understanding and investing in learning we can continuously improve our ability to deliver software.
I recently posted a tutorial demonstrating an MVP for Continuous Delivery in the simplest way I could. It only requires the use of Bash, Python and AWS, which should make it approachable for any developer who can code.
I want to help improve the quality of software delivery across the industry so please let me know if this is valuable to you or if you have any suggestions.
Follow me here for more content or contact me on:
- Twitter: @BenTorvo
- Email: ben@torvo.com.au
- Website: torvo.com.au
This content originally appeared on DEV Community and was authored by Ben Brazier
Ben Brazier | Sciencx (2022-07-04T04:55:29+00:00) The Truth About Continuous Delivery. Retrieved from https://www.scien.cx/2022/07/04/the-truth-about-continuous-delivery/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.