Tools for continuous integration monitoring of front-end
Tags: frontenddev
Published: 2019-07-08 17:39:24

---
title: Tools for continuous integration monitoring of front-end
published: true
tags: frontenddev
canonical_url: https://blog.logrocket.com/tools-for-continuous-integration-monitoring-of-front-end-dade4c32c929
---

![](https://cdn-images-1.medium.com/max/1024/1*DZ2ik6Ko0Opw9r2lMkclng.jpeg)

As a developer, you can greatly improve your process using continuous integration. You want to continually ship little changes you make and get them to the user as quickly as possible. You also want to monitor each deployment to ensure all is well at home.

Continuous integration (CI) is the solution. There are different tools that enable us to do this including Travis, Codeship, Jenkins, and more. These tools enable us to manage our deployment and monitor the entire process from start to finish. All you have to do is push to a repository and everything else will be taken care of.

[![](https://cdn-images-1.medium.com/max/1024/1*GPjaPKNNUYHU8EsA3Z0JGA.png)](https://logrocket.com/signup/)

### Why worry about continuous integration?

JavaScript has grown over the last few years in the amount of work it does in application development. If you pick up an old web design book, you will see things like “JavaScript is used on the presentation layer”. That is totally untrue at the moment, as JavaScript can go the full 9 yards of application development. This means what we do with our JavaScript at the moment is mission critical.

Same thing with your CSS. It almost goes beyond maintaining how your application looks, it can also be used actively in how your application works(transitions, and whatnot). Broken JavaScript results in a broken app. Broken CSS results in a completely disorganized application layout. How much would that impact the performance or usability of your application? What about the user experience?

Bearing that in mind, you want an automated way to handle the release of new versions of your application. You want to ensure that your dependencies work and that they are readily available. As your application grows, this becomes increasingly difficult to manage manually. I mean, how much do you trust your tired self on a Tuesday evening to verify that over 100 pages of your website work fine and all of the packages your app needs to run are installed?

### Starting with the build process: ditch npm, use yarn

The first and probably most ignored step in CI discussions is the build process. For many, this is usually not a concern. Once you set up your application, your node\_modules folder gets to hold all of your dependencies and you are good to go.

However, many times in each build, you do not get rid of the old node modules. You simply reuse them for the new application (and you may get away with this).

The challenge is that if your node modules are not up to date or if you have installed modules that are not in your package.json, your application may work now when ordinarily it should break so you can remove the use of a dependency in your project. This is because when you run npm install, it doesn’t clean house. It just looks for what’s new and installs it.

Yarn cleans house when running the setup process for your project. Yarn caches all of its installations and does not have to download them every single time you run yarn install. This is a huge win over npm that will always install everything afresh. Yarn checks and confirms that only dependencies listed in your package.json file are installed. This makes each yarn install give you a copy of the application similar to what someone who clones your app for the first time would have.

So, replace npm with yarn in the build process for your application.

### Testing

Automated tests are important if you would use a continuous integration and deployment. You want to ensure that your application works as expected before it gets to the live server. Your deployment process can be set up such that a deployment will fail if all test cases do not pass. This will protect your application in production and ensure you do not have a disrupted service.

Here are a few tools you can consider using for your automated tests:

1. Mocha
2. Jest
3. Chai
4. Jasmine
5. Karma
6. Protractor

You can read [An Overview of JavaScript Testing](https://medium.com/welldone-software/an-overview-of-javascript-testing-in-2018-f68950900bc3) for more

### Monitoring

This is the reason we are here. Monitoring your application deployment is important as it enables you to spot errors and fix them very quickly. It also allows you to focus more on the development and less on tracking your application and fixing errors. Also, it can greatly increase the productivity of your developers while raising your overall code quality at the same time. We shall now take a look at some tools you can use for continuous integration and monitoring.

[**Travis CI**](https://travis-ci.org/) is a hosted, distributed continuous integration service used to build and test software projects. It is very popular, widely used, and it’s free for open source projects (over 900k open source projects). As seen on Travis CI’s documentation, Travis supports your development process by automatically building and testing code changes, providing immediate feedback on the success of the change. It can also automate other parts of your development process by managing deployments and notifications.

You should check out Travis CI’s website to learn more about their build flow.

[**Jenkins**](https://jenkins.io/) is another really good CI/CD tool that is hosted on a server. It automates the deployment flow of your application, showing stages of each deployment as well as providing status so you can tell if the deployment was successful or not.

Jenkins can be connected to your repository and a commit can trigger a build. You can also set up a scheduled build using a cron or Jenkins dashboard and rerun a build process at any time. You can extend Jenkins features using plugins.

According to[**Codeship**](https://codeship.com/)’s documentation, “Codeship makes it easy and simple to get a working CI/CD process running through an easy-to-configure web UI and turnkey deployments”. Codeship comes in two variants — Basic and Pro. From the name, you already have an idea of what each would look like. Basic has a web interface for customization, it comes with pre-configured machines and does not support containers. Pro supports containers and allows you to define containers for your build environment. It also runs with configuration files that are specified in your code repository.

Codeship is a CI/CD tool that works on the cloud, unlike many others that are hosted locally with your application. It guarantees easy scaling of your CI/CD infrastructure and equally gives you one less thing to worry about. It also has customizable CI/CD automation that can speed up your deployments.

[**Raygun**](https://raygun.com/) is an application monitoring tool that tracks your application performance at all times, reporting errors in real-time. Raygun monitors the CI/CD process and can allow you to automatically reverse deployments with one click. It provides crash analytics and detailed analysis to enable you to tackle issues with your application.

[**Airbrake**](https://airbrake.io/) is an application monitoring tool that checks for errors in your code as well as affected customers and notifies you. It enhances your QA processes and helps you get to the root of issues in your code faster. Because it gives you scope and context of errors, you can efficiently prioritize fixes you need to make to your code.

Airbrake integrates nicely with other tools like JIRA, Slack and even your repositories, so you can set it up to monitor the entire stack of your application.

### Conclusion

There is so much to consider when setting up a CI/CD process for your project. Most importantly, you want to ensure that you maintain a high-quality codebase at all times. CI/CD, when properly set up, can help you achieve that.

Something worth mentioning is that you can use [Docker](http://docker.com/) in your CI/CD set up to deploy new containers where tests can be executed before moving the code to the intended server. Docker is great as it is lightweight and has a lot of people pushing containers to the hub.

I look forward to hearing stories of your exciting CI/CD exploits. Please do share them later.

### Plug: [LogRocket](https://logrocket.com/signup/), a DVR for web apps

[![](https://cdn-images-1.medium.com/max/1024/1*s_rMyo6NbrAsP-XtvBaXFg.png)](https://logrocket.com/signup/)<figcaption><a href="https://logrocket.com/signup/">https://logrocket.com/signup/</a></figcaption>

[LogRocket](https://logrocket.com/signup/) is a frontend logging tool that lets you replay problems as if they happened in your own browser. Instead of guessing why errors happen, or asking users for screenshots and log dumps, LogRocket lets you replay the session to quickly understand what went wrong. It works perfectly with any app, regardless of framework, and has plugins to log additional context from Redux, Vuex, and @ngrx/store.

In addition to logging Redux actions and state, LogRocket records console logs, JavaScript errors, stacktraces, network requests/responses with headers + bodies, browser metadata, and custom logs. It also instruments the DOM to record the HTML and CSS on the page, recreating pixel-perfect videos of even the most complex single page apps.

[Try it for free.](https://logrocket.com/signup/)

* * *