“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
Published almost 20 years ago, the first words of the Agile Manifesto still resonate vividly in the developer community. But what do they mean today? Is it really worth to be continuous in 2019?
With hundreds of articles, blog posts, and comments on CI/CD, the core value of the Agile approach has somewhat faded. Instead of helping developers deliver software faster, it became art for art’s sake. We spend tens of hours testing new tools, configuring delivery pipelines, writing bash scripts and fixing those scripts instead of doing actual work — just to be Agile.
Why has it come to this? Why has CI/CD has become a problem, instead of a solution? To answer this question, we first need to remember what does is it mean to be continuous.
What is Continuous Delivery really about?
Continuous Delivery, Continuous Integration, Continuous Deployment, Continuous Development… You can write a PhD thesis on every of these alone, and there will still be something to discuss.
There are three rules, however, which are crucial to everything continuous:
Rule #1: Keep everything in version control
Believe it or not, but there are still developers who don’t use version control in 2019. If you’re one of them, start right now. Application, configuration files, migration scripts, documentation — whatever you can, keep it in the repo. The only exception are dependencies and artifacts (unless your hobby is solving conflicts in code). Seriously, developing websites and not using VCS is like building a sand castle in the middle of a crowded beach and hoping it will still be in place when you come tomorrow.
Rule #2: Automate whatever is possible
Every manual process is prone to human error, especially repeatable tasks such as updating websites via FTP clients. Automation helps get rid of this problem, with the server always reflecting the contents of your repository, allowing for a quick rollback in case of problems. It also eliminates the dreaded phrase “works for me”, as preparing and deploying the build is common for the whole team.
Rule #3: Keep your deployment process boringly simple
No matter if it’s a static HTML site, WordPress theme, or a large SaaS project on Amazon EKS, the simpler your process is, the less effort it will require to maintain. Admit it: we, developers, love to complicate, adding new tools and weaving bash scripts the size of a Shelob’s network. We’d rather spend hours trying to make something work, and only then ask the question “do I really need it?”. Continuous Delivery is not about adding extra work, it’s about cutting the process to the bare minimum.
And, of course it’s all about money.
Why companies are failing with CI/CD
Let’s face it, the Agile Manifesto was written with one concrete purpose: to help developers be more competitive and cut a bigger profit. No matter if it’s a Jekyll website or a complicated microservice application run on a Kubernetes cluster — it’s all about making extra cash by cutting down on unnecessary stuff. So why have so few companies successfully adopted CI/CD in the last 20 years?
1. Process is overcomplicated
This is what happens when we forget about keeping the process boringly simple. We lose hundreds of hours configuring and running stuff which in the long-term proves redundant. Start with the most basic stuff. Review your work. If it works — leave it. Do not add until absolutely necessary.
2. Cost exceeds profit
On the other hand, there are hundreds of companies that do not automate processes at all, because nobody will pay them for the time spent on configuring and scripting pipelines (especially if the project is small). This is additionally reinforced by seeing CI/CD as something complicated and time-consuming (see pt. 1).
3. Tools don’t evolve
Although most of processes repeat in majority of companies, a great deal of CI/CD platforms provide nothing more than infrastructure in which you have to script everything manually anyway. Sure, they get the job done, but the adoption remains costly and time-consuming, often requiring to hire a full-time DevOps specialist to maintain the workflow.
As a team, we’ve been helping companies automate deployment for over 10 years, and the problems described above were common to every single use case. This is why we decided to create Buddy: to put the principles of the Agile manifesto back in the spotlight by developing a lightweight tool that can be easily configured in a couple of minutes. To help people save time and money by making the deployment process boringly simple again.
How Buddy does it in 2019
To realise what problems we’re facing, let’s have a look at a simple use-case: a static website served on Amazon S3. This is how the delivery process looks like in 2019:
- Developer codes HTML/CSS
- Files are processed with Gulp/Grunt/Webpack
- Deployment to SFTP/AWS S3
- Cache invalidation for quicker access
In theory, all these steps should be automated (except for coding of course). For that you need a developer that needs to be paid twice: first for coding the website, second for scripting the delivery in a CI/CD infrastructure.
This is how the process looks in Buddy:
This is a delivery pipeline in Buddy. Each of the steps is a predefined action that can be configured in 1 minute. For example, configuring S3 deployment boils down to selecting the bucket and the source path. Buddy will automatically deploy the files, set MIME, publish files, and set cache control. No bash scripts, no nothing:
The whole thing is optimised for maximum performance, too:
- deployments are based on changesets which means only changed files are deployed
- the repository and dependencies are cached in isolated containers, which massively reduces build times
Not all is static
The stack of a modern web developer is much more complex than a decade ago and includes a whole array of services, from task runners and bundlers to microservices, Docker, Lambda Function, cloud computing, and Kubernetes clusters. All of them are awesome tools which help deliver and manage software. However, unless you have a full-time DevOps specialist onboard, they are also much more difficult to automate.
Buddy got you covered here, too: with the help from our users, we have introduced over 80 actions that let you put all popular services on auto-pilot in a couple of minutes.
Key points to take away
- Version control is a must-have. A. Must. Have. If you don’t use version control, START RIGHT NOW. Seriously, it’s not rocket science: just a couple of commands starting with
gitthat will save your ass thousands of time. - Automate, but keep it as simple as possible. Do not let your developer instinct complicate things until absolutely necessary. Just don’t.
- Continuous improvement. Whatever you do, always review your work — whether it’s the application or the delivery process — and improve whatever needs improving. Step by step, one thing at a time. Continuous improvement might be the most important ‘continuous’ since the publication of the Agile Manifesto. It’s about the attitude, not the tools.
The Buddy Challenge
When we were designing Buddy in 2016, our aim was to create a tool that will help developers automate website delivery with minimum effort possible. Considering the feedback from the community, we have pretty much succeeded. Thinks all of the above is just a salesmen mumbo-jumbo? Let’s make a bet:
Create a pipeline for your project in Buddy. If Buddy fails to speed up your delivery, we’ll get you a beer.
Or a cake. Or a book, the best book on Continuous Delivery ever written. Seriously, if Buddy proves no use we’ll get you one of those one way or another. The rules are simple: sign up to Buddy, hook up your repo, and reproduce your workflow with our actions. If you feel no improvement, the gift’s on us. Also, when you’re on our website, make sure to use the SMASHING password on our live-chat and we’ll give you 30 days of trial with no limit on resources. And for all the freelancers out there, we have a forever-free plan with 5 projects, too.
And what is your takeaway from all of these? Do you think CI/CD sucks in 2019? Feel free to discuss in comments!
About the author:
Raphael is the CTO of Buddy and a DevOps evangelist with over 10 years of experience in delivery automation. Co-founder of Springloops, one of the first source & deploy solutions. A proud dad of three and a father figure to his buddies. Loves BBQ’s and Star Wars.
