In a previous post, we managed to set up different environments for development and production, with the same crucial settings for both projects, but there is one concern left. At this point, we need to manually deploy to the development or production project. Firstly, we can easily forget to deploy. Secondly, we might accidentally deploy to the wrong project. If for some reason, the concept of Continous Integration and Continous Delivery is new, it is perfectly summed up by Jeff Delaney in under 2 minutes.
We can utilize GitHub Actions to automatically deploy on every push. We want to have an automatic build and deployment for production every time we push something.
In our repository's
/.github/workflows folder, create a file called
firstname.lastname@example.org. The script below does exactly what we want to do on the master:
- Creates a Ubuntu VM
- Sets up Node on it
- Retrieves dependencies from the cache, if it is possible
- Install the project's dependencies
- Runs unit tests
- Builds the project
- Deploys it to Firebase, both to my master and dev environment
The first steps are best explained by the official GitHub Docs. Caching and installing npm dependencies are also well explained there. To make that work, we must set up a secret in the repo named
FIREBASE_TOKEN, where the value is the token we get when we sign in from the CLI using
firebase login:ci. The
PROJECT_ID must match the project name in Firebase.
We have implemented CD support for our Angular&Firebase project. We enhanced CI by failing as soon as possible using automated tests. To further improve, it might be a good idea to run tests on pull requests too. To do that, we only need to change the trigger at the beginning of the file from
pull_request, remove the last three steps, and put this into a separate YAML file.