Create CI/CD pipeline

[00:00 - 00:10] Continuous integration is an important practice that helps catch bugs early and ensures code quality. One code is committed to our default branch, usually called "Developer Dev".

[00:11 - 01:16] We want to make sure all tests are before we go ahead to merge into the main branch. GitHub Actions makes it easy to set up a CI pipeline that automatically runs our test suite on every push to our Dev branch. We create a yaml workflow file that defines the jobs, containers and steps to test our code. To create a workflow file, create a .g uitar folder in the root part of your project and then create a workflows folder inside the .guitar folder and then create your workflow file. The title can be anything. In this workflow file, we specify that anytime we push to gh-action branch, it will set up the necessary environment, install dependencies and run npm tests. A workflow file is made up of different jobs and each job contains different steps. In this job, we specify that our CI pipeline should run using Ubuntu and we also set up a MongoDB database. Remember, in the earlier modules, we run our integration tests against an actual MongoDB database before we introduce test containers.

[01:17 - 02:47] We still want those tests to pass. Hence, we set up a MongoDB database to run in our CI pipeline. We also install Docker into our CI pipeline and also set up node. And then lastly, we run npm clean install and then we run our npm test. And when we run npm test , we pass this environment variables, MongoDB, AWS secret and rapid API key. As the best part is never checking configuration details and secrets into your Git repository. This can open you and your product to security, which is also used secrets in GitHub actions. We have to set up secrets in the repository as our GitHub repository. Under the settings tab, go to secret and variables and click on actions. You can add secrets here by clicking the new repository, security name and a value at secret. All of these secrets are available to our GitHub action. One last bit I would like to watch on is I've separated the test into two different categories. The integration test is in this folder and the unit test is in this folder. This is so that in our pre-commit hook of Husky, we want to run just the unit test. Unit tests are usually fast and will give immediate feedback to the developer. So we don't delay or interrupt the development workflow. In our package.json, we can go ahead and remove this given that the configuration is already contained in this. We commit for our guide and commit these changes.

[02:48 - 03:21] I've pushed the commit to GitHub, our head over to GitHub so that we can see our CI pipeline action in our GitHub repository. Under the actions tab, we can see our CI pipeline running our click on it so that we can see the progress. Our action has completed successfully and all the tests run without failing.

[03:22 - 03:40] This means that our most recent commit can be matched into the main branch. With GitHub action in place, developers can get immediate feedback on failures and more importantly, we prevent any broken code from being released. Adding automated testing on branches is critical for maintaining quality as