MileciaThe software development life-cycle has a lot of moving parts. A huge problem many large companies had was maintaining consistent a deployment process. Written steps sometimes get skipped, manual deploys are error prone, and home-grown deploy scripts are usually only understood by the person that wrote them. Companies like Netflix, Etsy, and Amazon need to make sure that deployment cycles are smooth and errors are caught as early in the process as possible.
When you have problems consistently getting to production where the customers are, your company will start to lose the trust and confidence of the users. That’s where DevOps comes in.
What is DevOps
DevOps is a shift in the way a company handles its deployment process. In many organizations, the code is handled by developers and the deployment is handled by the operations team. The fundamental problem that DevOps solves is the slow turn-around time for bug fixes and new feature releases.
The Waterfall cycle is still commonly used and its biggest drawback is how long it takes to get from development to deployment. In the DevOps culture, developers have some control over the way apps get deployed to production. This makes it easier to get changes out faster, more consistently, and with less errors that effect the user’s experience.
In DevOps, you’ll notice that the flow is similar to the Waterfall cycle but it’s more streamlined and automated.
The DevOps Cycle
There are different parts of the DevOps life-cycle: Version Control, Continuous Integration, Continuous Delivery, and Continuous Deployment. Version control is something that developers work with all of the time in the form of Git and another tool like GitHub or BitBucket.
What is CI
Continuous integration is one of the first things that developers get introduced to in the DevOps chain. This is the part where your code gets compiled, reviewed, and tested. We’ll go through the flow of a typical CI/CD pipeline assuming we’re trying to deploy a web application to production.
Most DevOps pipelines will be triggered from a push to a branch or some other set of conditions around commits. This starts the build phase which is the beginning of most pipelines.
In the build phase all of your code is compiled to make the artifacts that will eventually get deployed. Right after your app has been built, the first round of testing will start.
This is usually when your unit tests will run and weed out any of those simple code bugs. If any tests fail here, it will send a notification to the developer or team that worked on those changes.
The point of all of these checks in the initial stages is to make sure that problems get addressed as early as possible. You don’t want to get a built artifact all the way to the deploy phase and find out you have a mis-configured form in production because somebody used a double equal comparison instead of a triple equal comparison.
That’s one of the big goals with DevOps in general. Detecting and fixing bugs and security issues as early as possible is important when you are deploying changes multiple times a week or even a day. This saves you time by stopping the rest of the pipeline from running when an issue occurs. You aren’t waiting until the very end to get feedback to developers.
Once the unit tests finish, it’s likely your artifact will get deployed to a staging or quality assurance environment.
What is CD
The “CD” part of CI/CD actually represents two stages in the DevOps flow: continuous delivery and continuous deployment. Continuous delivery is the automation behind pushing applications to different environments.
This is where integration tests are commonly run as well. Many times this deployment is handled in parallel with other tasks. You might also be clearing the cache for the servers you’re deploying to or setting configurations based on the environment you’re deploying to.
This is also when your application starts getting pushed to the appropriate service, like a database service or a web server. Continuous delivery is like the test run for deploying to a production-like environment before you push the changes to customer facing servers. Once you’ve run the last few integration tests, handled some Q/A testing, and gone through some security testing, you have a valid code base that’s ready for production.
Continuous deployment is the overall goal DevOps is working towards. This is when your code changes finally get released to production and get to the customers. The main reason CD is needed in DevOps is to remove all of the manual steps that operations were going through. When you have a bunch of steps that people need to do, there are always going to be little things that slip through.
Whether it’s something as simple as not updating an environment variable or it’s something like an empty artifact getting deployed to production, continuous deployment is one of the ways to address that problem.
Pros of CI/CD
- Deployment of code changes is less risky.
- Removes the manual deployment steps.
- Faster shipping speed.
- Increased code coverage.
Cons of CI/CD
- It takes a lot of upfront investment to set up a CI/CD pipeline.
- A lot of automated tests have to be written.
- There has to be a cultural shift within the company for DevOps to work.
- Legacy systems often don’t support CI/CD.
Considerations before trying CI/CD
If you’re wondering whether or not you should try to implement a CI/CD pipeline for your project, here are a few things to think about.
- Are there a lot of manual steps in your deploy process?
- Do bugs get to production regularly and frequently?
- Do you have to coordinate multiple services and code bases?
- Is there only one person on the team that knows the whole deploy process?
- Would you have to make large upgrades to the code base?
- Can you get support from other parts of the company to get this started?
- Have you had issues with compliance audits?
- How often are you able to security testing with your current process?
- Can you consistently and reliably get small code changes to production?
- Would this help decrease the number of support tickets your team has to handle?
Tools
There are a number of open-source and enterprise level tools available for building CI/CD pipelines. It'll pay to do some research on a few of these to find what works best for your application.
Other Thoughts
There are a number of strategies you can implement when you're building your CI/CD pipeline. It mostly depends on what you're trying to get to users. If you have a lot of microservices and third party services, you might look into some kind of orchestration strategy. If you have an existing dynamic application, you might want to focus on the testing phase of the pipeline.
Implementing even a basic CI/CD pipeline is likely to save you hours of debugging time and make your deploys go smoother. It does pay to take your time and look around for the best tools for your project. Choosing something that is both cost effective and has the features you need is a balancing act, but the customer satisfaction you will produce will be worth it.
If you’re wondering which tool you should check out first, try Conducto for your CI/CD pipeline. It’s pretty easy to get up and running and it’s even easier to debug while it’s running live.
Make sure you follow me on Twitter because I post about stuff like this and other tech topics all the time!
