Boosting your development and delivery times with CI/CD

It’s essential to organize your development and delivery process in a good and efficient way. So at this point comes DevOps solutions which can help you to automate lots of things in your project. Anything which can be automated in your system can save up your time by reducing and improving your teamwork, speeding up your project development and delivery time in multiple times.

Let’s start at the very beginning and understand how our approach helped us.

Beginning

Everything starts from lots of test cases. It would be better to have multiple types of them (i.e. Unit, Integration, Regression and etc). In our case, we have Unit, Integration and some Security tests. Additionally, we use a syntax checker to detect bad syntaxes in our project’s code base.

You can also have other checkers too, for example, coverage checker, which will inform you about some parts of your code that haven’t been covered by your tests. Anything which allows you to check your code base will be helpful for you to automate your system.

The second most important thing is the choice of the correct and good tools which will help you on the way of system automation.

Continues Integration

We use Jenkins to run continuous integration jobs, which builds and tests. In our case, Jenkins watches to our Github repositories (via Webhooks). So any PR(Pull Request) which is created or changed by the contributor should be verified by the Jenkins job. There is a small icon (i.e. pending, failed or passed) for each PR which shows the job status. In that way, we can easily review the changes and be sure that it doesn’t break anything and it’s written correctly.

Failed CI job for a PR:

Successful CI job for a PR:

Even you can restrict and disable particular commits to the master branch.
Allowing to make changes on the master branch with PRs, which the CI job will check and mark as verified change.

In my opinion, pushes to the master branch should always be restricted. As the master branch is the most important branch in the repository(take the master branch as production ready branch into account) anything you want to merge with the branch should be verified. Sometimes you may not feel like creating a new PR for a single small change (i.e. typo fix), in that case, most of the developers just ignore the CI phase, and who has admin permissions to the repository they can push to the master branch without any verifications.

However, be 100% sure about your changes before pushing something to the master branch without checking/testing your changes.

Continues Delivery

We run our systems in Heroku. It’s a cloud platform as a service which provides lots of features for CI/CD. Anyway, we use only CD features because the CI part is already implemented with Jenkins.

Despite Heroku’s having lots of features in this article, we are going to discuss its two main features that are used for our systems.

Pipelines

It allows as to create staging and production systems and connect all to each other. So we can easily move a system version from staging to production. It helps us to have separate systems for real users(production) and for the management team(staging).

You can also have a server for the development process where the development team can test their changes and then move the changes to the staging system.

In the image, we have two types of systems (staging and production). In the same way, you can have three types of system, including the development one.

Also, notice that in the production we have two applications instead of one. You can create multiple applications with different environments for your production system. /if you promote the staging to production then both of applications will be restarted and changed.

More about Heroku Pipelines here.

Review Apps.

If you use review apps or such kind other tools for your project then most probably you can't imagine your workflow without that for other projects.

It's a very useful and time-saving feature but mostly for the UI developers, but in some cases, it’s possible and helpful to implement it for the back-end.

Imagine your colleague is working on a UI feature and asks you to review the changes. You can review the code from Github because all file changes are visible there. But you can’t check and verify the final result for the clients.
So you should download the new branch or pull new changes to your local machine then build the project and check the final result in the browser. It’s time-consuming activity for developers because there can be some errors in the build process, or there can be new necessary libraries which you should install etc. But with Review Apps, it’s very easy. We don’t need to fetch/pull the new branches and build, and then start to review the changes. Because it’s already deployed as a separate application and have a custom URL address.

So you can click on “View deployment“ button and see the changes for screenful-api-staging-pr-11. This last number is the PR number. So the full URL address would be something like this:
https://screenful-api-staging-pr-11.herokuapp.com

There are also other tools which provide such kind of feature(i.e. https://zeit.co/) or you can create your own with Jenkins and AWS.

Summary

So this approach speeded up our development and delivery time in few times.

First of all, we can be sure that there is nothing wrong with our changes because the CI job has already checked and verified it.

Second, if there is something wrong in production then we can easily rollback the current version and use a stable version.
And the last most important thing for us is Pipelines and Review Apps which are very useful and time-saving features.

CI/CD can be organized in different ways with different tools depending on your needs. You should choose the most comfortable way for your team and your business.