How simple changes made huge difference in our development process

I am front-end developer at Digital Engineering team of Pasha Bank. Our department is established to transform traditional bank products into digital ones. So, most of the coolest tech stacks are used to give the best experience for our customers. React (with hooks ✨)+Redux, Typescript, Jest, Enzyme are our stacks in front-end. When I started to work at this company number of front-end engineers and code base were significantly less than now we do. At that time we weren’t experiencing any kind of issue regarding to deployment or development time. But, things started to getting worse over the time, just because number of squads is increased (for sure new engineers have been employed), code base started to bubble up and yes, shit has happened.

What our deployment process looks like

We have two separate branch for production (master) and development (dev). Whenever we start to do a business task, firstly we create feature branch with proper task name. After getting everything done, we create pull request to merge into dev branch.

Branching strategy

What is the best way give our customers newly made features easily and quick? Power of continuous integration! And we are using CircleCI for it.

Problems:

1. As I mentioned before we are using Jest and Enzyme for automated tests. So in every push to branch or whenever something merged all tests were running which takes about 4–5 mins (growing as new features are delivered).
2. We have limitation in CircleCI to run 6 jobs in parallel. More front-end engineers means more jobs are queued in CI.
3. Built and tests steps were running in sequence (steps) where they were independent and could be run in parallel.
4. Sending test reports and analysis to SonarCloud was another big step which was taking approximate 3 mins.

Deployment flow in CircleCi (jobs and duration is shown with red)

Waiting for this flow to get your things deployed was a disaster. Think about when someone merges feature to dev branch before you and now you have to update your branch so you need to wait another 10 mins……

Now it’s time for solutions!!!!

1. Running all tests whenever you push something to your branch is not that good idea. When it takes so long time it means job stacks in queue for long time and other developers need to wait for it. So I found out that Jest has great feature which gives you ability to run only tests related to changed files. If you have changed one file, only tests related to it will be running. So I added script like this below.

But to be sure that everything works fine and we are not going to get a phone call in the middle of the night, we are running this script if we push our changes to feature branch. Still running all tests in dev and master branches. For this just add the test job as below:

2. Pushing commit to the branch in sequence was filling queue with useless jobs. For example, you have branch feature/X you made some changes with commit name Changes 1 and pushed it from local, jobs related to Changes 1 are running. Then you made another quick fix with name Changes 2 and pushed it, jobs for Changes 2 also start. Now there are 15 engineers working on same repository and developing tasks without stopping. After researching a little bit I found out that CircleCI has a nice feature called Auto Cancelling a Redundant Build. After enabling it we finally got what we want.

Auto Cancelling a Redundant Build

3. Two of our CI job steps were running in sequence: build and test. Where they are totally independent and could be run in parallel.

As a result I separated them as an individual jobs to run them in parallel, now it looks like this:

If they were taking 3 mins for each before it was 6 mins. Now if they start to run as parallel jobs it will take only 3 mins. Hoorays!!!

4. The last improvement is related to sending result to SonarCloud. We were doing it as a part of CI job as a step.

If you use SonarCloud Automatic Analysis in your project, you will get automatic code analysis in your pull requests.

Result?

At the end we had optimized lots of things from cancelling not needed jobs to decreasing time needed for deployment. if full deployment flow was taking 17 mins, now it takes around 6–7 mins. Everyone loved it!

Thanks goes to our DevOps team member and tech lead (at the time) Rashad Amirjanov for his help during the process!