As you can see from the previous flowchart, continuous integration only covers the build and the test steps. It ensures that the code is tested before deploying to servers. Even though it is considered the least mature practice among the three, we still need to write enough unit tests and integration tests to keep the test coverage at a high percentage. Otherwise, it cannot really be called continuous integration.

To achieve continuous delivery, we will need to deploy the code to the staging environment automatically and then execute E2E tests automatically. In our application, we write our E2E tests based on Nightwatch.js. As mentioned before, in those tests, those mini-robots will actually open the application inside a browser and then test features the same way a human being would do. It is a test from the frontend all the way to the backend. Sometimes, these tests are called automation tests, in contrast with the manual test a QA colleague will do. Using an automatic E2E test is a great improvement for the entire software development process because it releases us from having to do those tedious tasks ourselves so that we can focus on building a better application. However, this benefit comes with a cost that is the effort to write a comprehensive E2E test suite.

Between continuous delivery and continuous deployment, the difference is that, in continuous deployment, the build is automatically shipped to the production environment. This is the most mature process that, on the other hand, requires the best testing culture. Since a change is shipped automatically, our tests need to be able to protect the quality of the release. Broken features or issues must be detected during the test phases. Sometimes, it requires feature flags that we can use to turn new features off by default when they are shipped to production so that we can coordinate with other team members to roll the feature out gradually, as well as keep the damage, if there is any, manageable.