5 Strategies for Smart DevOps in Single Page Apps
Today, DevOps plays an integral role in the development lifecycle. Besides, most of the frontend frameworks come with a module bundler such as Webpack that takes care of the heavy lifting. However, we still need to plan on how to connect the frontend bundling with CI and CD environments.
In this article, I will discuss five strategies that you can consider when you consider DevOps for Single Page Applications.
1. Reduce Environment Configurations
When we create the structure of a single page app with React, Angular, and Vue, it’s a common practice to use a separate configuration file per environment. Typically, we keep an environment configuration for Development, Production &, etc. Sometimes this grows to several files if each environment differs from one another.
But what if we stick to only two configurations for Development and Production for different bundler configurations, while other application specific variables like API paths, Host Name &etc. are modified after the build?
By keeping these two configurations, you can separate the local development configuration from the rest (Production, Staging, and QA).
If you divide the Build and Release into two pipelines, you can reuse the Build pipeline to create one build artifact with placeholders intact first. Then depending on the deployment environment, you can dynamically replace these variables at the Release pipeline. There are two main advantages you gain from this approach.
- You can push the same bundle to multiple environments (with basic string replace step), saving precious build time.
- Knows the exact difference you make to the bundle, specific to the environment.
Tip: Share your reusable components between projects using Bit (Github). Bit makes it simple to share, document, and organize independent components from any project.
Use it to maximize code reuse, collaborate on independent components, and build apps that scale.
Bit supports Node, TypeScript, React, Vue, Angular, and more.
2. Setup Quality Gates
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.
3. Caching Package Installation
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.
4. Look for Parallelism
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.
5. Effective Execution of Automated Tests
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.
Conclusion
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.
