Today it’s a common practice to build the frontend before any Pull Request is merged to the development branch.
The concept of Quality Gate connects with Pull Request build, where you can setup additional steps (or Gates) to ensure quality.
For example, you can have a build step to execute linter operations to ensure any code modified or added doesn’t have any deviations from the already followed code style. Going one step above, you can use advanced code quality tools like SonarCloud to measure quality and provide the feedback to the Pull Request itself with detailed insights.
You might wonder, why not do these code quality evaluations at the IDE level even before the code is check-in? Yes, it’s essential to do these evaluations at the IDE level (if any IDE plugins are available) to avoid the feedback cycle time. However, it’s equally important to keep the Quality Gate to enforce it for overall code quality governance.
If you look closer to the frontend build execution time, NPM package installation takes a significant part of it. When we do repeated builds, it’s difficult to justify this time since we rarely change the external dependencies.
As an improvement, you can setup a caching step to cache these dependencies. In specific DevOps platforms like AzureDevOps, there are predefined steps to do this. However, if you can’t find one in your DevOps platform, you can create a hashing function based on package.json content and use it as the cache key to perform the same operation.
When we build web applications at DevOps pipelines, in some cases, we need to build both frontend and the backend. Since most of the DevOps platforms support parallelism using Agents, we can separate the frontend build and the backend into different Agents.
By following this approach, we can reduce the time it takes to complete the build.
If you divide the DevOps steps to Build and Release pipelines, you can even combine the frontend and backend build artifacts at Release pipeline (If both deployed to a same server).
Besides, there could be additional steps even within the build pipeline of which you can perform parallelism. The important message here is to try out different optimizations with parallelism and measure the impact it makes for the overall DevOps and improve based on the lessons learned.
Finally, I want to take up a crucial step that we need to set up in DevOps pipelines.
Although the best approach is to execute these steps at Pull Request level (or even better at developers machine), we need to decide the right place based on the test execution time.
For example, it’s a common practice to execute Unit Tests at Pull Request build as a part of the Quality Gate. But running E2E tests at this level could become an overhead if it takes a few minutes to execute (which happens often). Therefore it is essential to assess the situation and decide to run the E2E test cases at a different level.
For further details on the importance of automated tests, you can refer my article on Things to consider when frontend unit testing.
As you can see, there are different DevOps improvements we can do to increase efficiency as well as to enhance the overall quality of the Application. Besides, some of these techniques are equally applicable to backends as well.
Though the article discusses five strategies, the direction of these strategies might help you to figure out further improvements to your pipelines. For instance, you can also consider the technique of caching at various levels depending on your build steps to enhance its performance further.
However, it’s also essential to note that each of these improvements comes with a cost. If I take the same example of caching, you should know that there is a chance of not using the latest updates of libraries for the builds even though you specify for automatic minor and patch updates of NPM dependencies.
At last, I hope these steps will help you to be better at DevOps and improve your existing pipelines. If you have further questions, you can put them in the comments below, and I would be happy to help at the best of my capacity.