The Journey Build Continuous Deployment @Sleekr
Dream come true and DONE means DONE!
Deploy Deploy Deploy!
Yup deployment is one of the steps to deliver our features or bug fixes in our apps. most deployments have a workflow. The deployment workflow is a trigger when apps ready to deploy to a production server. Maybe if QA said OK, maybe if PO (Product Owner) said OK, or the BOSS said Deploy! 😁
Anyway, Last 2 months Sleekr implement Continuous Deployment. Where all steps automated by tools. It’s an exciting and interesting part. I will share our journey to make it happen.
The Problem
We spend a half day to deploy the latest master to production and only specific engineers know how to deploy to production. every working day we can only deploy 1 until 2 deployments. We create schedule deployment who deploy this week and rolling every week.
We have a lot of preparation such as create a release version, tag the JIRA ticket, deploy to the staging server, and tagging code repository with the release version we want to deploy. Where all steps are a manual process!
Sometimes we are not deploying because of tasks we have and deploy when we found bugs 🤓. Let’s imagine when we don’t deploy the latest master while 2 days, while we don’t deploy there’re features merged into the latest master. And we start collects info to the team to ask if there’re deployment notes. It’s scary!!!
Definition of Done
DONE is ambiguous when the engineers said the features merged into master, reviewers said approved the features, and QA said done sanity check on the staging server. Done should be clear, means the features or bug fixes were deployed to production and delivered to customers.
DONE means DONE, which means development done, code review done, sanity check done, and do it with best practice way.
CI/CD
Start from our dreams. Dream about no repetitive task, no deployer manager, no schedule who deploy this week, and no drama. When we need to deploy the latest master to production.
We start from a weekly meeting to discuss where we should start. We start from defines the steps, and we stick to start with CI/CD. why do we start with CI/CD? because when we want to implement Continuous Deployment. the CI/CD is fundamental of Continuous Deployment.
CI (Continuous Integration)
Continuous integration assumes that only a part of the process is automated and that human intervention is needed after machines are finished with their work. That intervention often consists of manual tests or even manual deployments to one or more environments.
We start using Bitbucket Pipelines to create CI (Continuous Integration) and defines the pipeline steps:
- Clean Code (Rubycritic)
- Coding Standard (Rubocop)
- Code Security (Brakeman)
- Unit/Integration Test (Rspec)
- Code Coverage 90% (Simplecov)
The CI (Continuous Integration) will run after engineers push codes to any branches.
CD (Continuous Delivery)
Continuous delivery is an extension of continuous integration to make sure that you can release new changes to your customers quickly in a sustainable way. This means that on top of having automated your testing, you also have automated your release process and you can deploy your application at any point of time by clicking on a button.
After successfully created CI(Continuous Integration). We create a CD(Continuous Delivery) to easily engineers, QA, or PO deploy to Staging Server. Like the CD means. The deployment decides by business people or there’s a button to click for deploy.
Blackbox Test
After building CI/CD. We still not confident to continue to the next step (Continuous Deployment), because there’s a legacy system we need support. So, we decided to create a Blackbox test to test our legacy system and edge/complex test cases. we created with Cucumber and Newman.
Continuous Deployment
Continuous deployment is almost the same as continuous delivery. All the steps in the process are in both cases fully automated. The only difference is that the button that says “deploy to production” is gone.
After we have great CI/CD and Blackbox Test. We start to create Jenkins Job Continuous Deployment for chaining the deployment steps we have. It’s like completing puzzles. we created some Jenkins jobs:
- Deploy to Canary Server
- Blackbox test on Canary Server
- Build release image
- Create a release version or tagging
- Deploy to Production
Then wrap in 1 Jenkins Job, the Jenkins Job Continuous Deployment. All of the jobs run by disposable nodes and Kubernetes Helm in the background.
Summary
So our dream come true after we unleash the Continuous Deployment. Now we are more agile, our Continuous Deployment deploys with blindly. Before we deploy maximum twice a day, now we can deploy until 6 deployments to production. so many benefits after we implement Continuous Deployment.
The problem solved and no blockers in our process deployment. Our development team happy and customers happy with delivering the features or bug fixes fast and safely. Only merge into the main branch and the deployment automated by tools. DONE means DONE!
