Five easy ways to automate 🤖 your software development process with Github Actions. Lean how to build CI/CD pipelines and other awesome DevOps workflows. 

- Special Thanks to Marc Stammerjohann for the Firebase Github Action Guide https://fireship.io/snippets/github-actions-deploy-angular-to-firebase-hosting/
- Demo Code https://github.com/fireship-io/225-github-actions-demo
- Github Actions https://github.com/features/actions

#devops #github #tutorial

Install the quiz app 🤓

iOS https://itunes.apple.com/us/app/fireship/id1462592372?mt=8
Android https://play.google.com/store/apps/details?id=io.fireship.quizapp

Upgrade to Fireship PRO at https://fireship.io/pro
Use code lORhwXd2 for 25% off your first payment. 

My VS Code Theme

- Atom One Dark 
- vscode-icons
- Fira Code Font
2024-02-04T06:19:41.108Z
nova-2
2-general-nova
2024-01-09.29447
30089e05-99d1-4376-b32e-c263170674af
034f84d2-30fd-4c8b-a200-374f573bd9aa
60249c752ee763ffb30bf4647f840bebd83ee176ef11b3e94987f3912b41a255
67875a7f-c9c4-48a0-aa55-5bdb8a91c34a
deprecated
One of the best ways to increase productivity in a software project is to automate anything manual or repetitive, and you might be surprised at how easy automation is to implement when you use an awesome tool like GitHub Actions.
In today's video, we'll look at 5 different techniques that can improve the quality of your code and make your life more productive through the magic of Dev boss.
If you have no idea what terms like Continuous Integration and Delivery mean, you will by the end of this video.
And if you choose to follow along with your own project, we will automate the hell out of it.
If you're new here, like can subscribe, and grab the full write up from FireShip.
Io.
Before we get started, I'd like to take a second to say thank you, because the channel just surpassed 300,000 subscribers.
To celebrate that, I have a big giveaway UI plan in the next 100 seconds of code video that everybody can participate in.
Stay tuned for that in a couple days pending the apocalypse.
We're all gonna die.
Now to get started with today's video, the only thing you really need is a GitHub repository, and the service has a very generous free tier, so don't worry about paying for anything upfront.
Now before we jump into these 5 different DevOps recipes, let's answer the question of what is GitHub Actions?
Consider a repo one GitHub.
There are all kinds of different events that can happen to that repo.
Someone might start the repo, send a pull request, or you might merge code into the master branch.
These are examples of events, and any event can trigger an automated workflow.
A workflow can spin up 1 or more containers for you in the cloud, then you provide a set of steps or instructions for the container to do something useful for you.
GitHub will log the progress of each step and make it very clear if something failed.
Now the really cool thing about actions is that instead of writing your own steps from scratch, You can use ones implemented by the community.
You can think of each step as a reusable chunk of code, which we call an action.
On GitHub, you'll find hundreds of reusable actions that solve common problems, with each one being its own git repo that you can fork and customize as needed.
But I think the best way to get started is to look at some real world examples.
A good starting place is continuous integration, And if you have no idea what that term means, make sure to check out my 100 seconds of code video on that topic.
The whole idea behind continuous integration or CI is to have developers submit their code to the main code base in small maintainable chunks, usually on a daily basis, and those changes should be automatically tested against the main code base.
Let's take a quick tour of the code.
Inside the package JSON, you can see I have a set of scripts here.
We use Jest to run automated tests and then build to build the app with Webpack.
The app itself is just a simple website that tells you what day of the week it is.
Inside the source directory, we have app JS with a JavaScript function that implements that logic.
And then we have app dot test dot j s to test that logic.
Feel free to clone this repo if you want to use it as an example, or better yet, use your own project as a starting point because these principles apply to any GitHub repo.
When you visit your code on GitHub, you'll notice this actions tab.
This is where you can monitor your workflows.
When a workflow is triggered, it will give you a log of everything that happened on the server.
What we wanna do for continuous integration is have our test suite run anytime there's a pull request to the master branch.
If the test suite fails or if the code fails to build, we should get a red check mark here, automatically telling us not to merge that pull request.
But but if everything goes according to plan, we should get a green check mark.
Now back in the source code, you can see I have a GitHub directory followed by workflows, and a file called integrate dot yaml.
Anything in this workflow's directory will be picked up by GitHub and automatically set up as a workflow in the cloud.
The YAML file is where we define the workflow.
Flow.
We'll give it a name of node continuous integration, then we need to tell it on which event or events to run.
We do that with the on object, And in this case, we want to run it on pull request to the master branch.
Now every workflow should have 1 or more jobs.
You define them on this job's object, and then first give the job a name.
We'll call this one test pull request.
From there, we need to tell the job which VM to run on.
I'll run this one on Ubuntu, but you also have the choice of Windows and macOS.
Next, we need to give this job a set of steps or instructions that actually build and test our code.
We'll first want to get our source code into the virtual machine.
We can do that using an officially maintained action called checkout.
That brings your source code into the current working directory, And that means you can run commands like you would from the command line if working on the project locally.
But in our case, we also need to set up Node.
Js in order to run those commands.
So we use the node setup action and then specify the version.
And from there, we're ready to start running our own commands.
We first need to install all of our dependencies from npm, And we can do that using the c I command.
That's equivalent to npm install, but it does a clean install for your c I server.
From there, we'll run our test command to test our code.
And then after that, we'll run our build command to make sure the build compiles properly.
Now it's also worth noting that if you have a more complex test suite, like end to end tests with Cypress for example, There's very likely an existing action to set up the test runner for you automatically in the environment.
And that's all it takes for the workflow configuration.
To start using it, we just need to commit it to the master branch.
I'll run git add, git commit, and then git push to push that to the remote repository.
Now if you go to the actions tab on GitHub, you'll notice that it's still empty.
That's because we haven't had an actual pull request event to trigger a workflow.
So let's go ahead and give our workflow a spin by creating a pull request.
I'll go ahead and create a new branch using git checkout with the b flag to automatically move into it.
Inside that branch, I'll make some changes to the source code that caused the test to fail.
I'll then commit those changes and then push this branch to the remote repo.
When I go back to GitHub, I'll see the option to create a pull request, which I'll go ahead and do.
And you'll notice that it indicates how we're running checks or continuous integration tests in the background.
If we go to the actions tab, we can see logging for this process running in real time.
In this case, the test on the pull request fail, which means we probably shouldn't integrate this code into the main code base.
And as the developer who submitted this code, I can look at the logs and realize what I did wrong.
In this case, since I have an open pull request, I can go back into my code and fix it and then push another commit to this branch.
GitHub will automatically rerun the workflow because this is an open pull request, and this time around we get green check marks.
So that takes care of our continuous integration.
Now it's time to move on to the next phase, continuous deployment.
At this point, we're confident we have a valid pull request, And when we merge that code into the master branch, we also want to deploy the app to our customers.
So continuous integration is about merging new code into the code base, while continuous deployment is about pushing that code out to your customers.
To demonstrate this, I'm going to integrate a third party host, Firebase.
And I'd like to give a shout out to Mark Stammaryohan.
He put together an awesome guide that will take you through each one of these steps, so make sure to check that out on FireShip IO.
We can easily set up hosting locally by running firebase init hosting, then we can push our code to our Firebase hosting account using Firebase deploy.
We can do all this locally because we're authenticated into our Firebase account on our local system.
But how do we authenticate a remote CI server to do the same thing?
What we'll need to do is share a secret token with GitHub.
We can obtain that token from Firebase by running Firebase login c I.
This will return us with a token string, which you can think of as an API key or username password combination.
Make sure to keep this value secret.
Go ahead and copy the value from the command line, and then head over to your GitHub repo, go to settings, then secrets, and add a new secret.
We'll give it a name of Firebase token in all caps, and you'll wanna make sure to use that same name.
Then we'll paste in the token and save it.
GitHub will automatically encrypt this value for us, and then we can access it securely from our CI server.
In other words, it gives us a way to securely authenticate with Firebase from a GitHub Actions workflow.
Now let's go ahead and create another YAML file in the workflows directory.
This one we'll call deploy.
Instead of running this workflow on a pull request, we'll run it on a push to the master branch.
So this workflow will run if we push code directly to the master branch, or if we merge a pull request into it.
Now the job itself looks almost identical to the previous job.
We check out the code, set up node, run our build command, but then we need to deploy it.
And to do that, we're going to use a third party action called the Firebase action.
This action takes care of all the steps required to set up the Firebase CLI on your server.
It will run the Firebase command, and then we tell it to use the arguments of deploy only hosting.
Then it's going to be looking for an environment variable of Firebase token.
We can access our secret GitHub value by using dollar sign, double braces, followed by secrets dot firebase token.
And that's basically all there is to it.
We can start using this continuous deployment workflow by pushing it to the master branch.
Now if we go back to GitHub and merge that pull request from the previous example, You can see from the login that it automatically builds and deploys our code to Firebase, and the changes should be automatically reflected on the website itself.
And now that we have a basic CICD pipeline, I wanna look at some other cool things you can do with GitHub Actions that you might not realize.
Personally, I maintain a few open source projects that are available as libraries through NPM.
One of those projects is Svelte Fire.
And anytime there's a major code change on the master branch, We cut a new release so developers can use that code in their projects.
And every time that happens, I also need to go to the command line, log in to npm, and push that code to the npm registry.
It's kind of annoying and easy to forget, so let's just automate it with GitHub Actions.
In this workflow, you'll notice I'm using the release event.
That's because not every code change on the master branch requires a new release.
For example, if you just fix a typo in the Readme, it doesn't require a whole new release to be pushed out to NPM.
PM.
In this recipe, you'll notice we have 2 jobs, 1 for build and one to publish to NPM.
And we might want an additional job to publish to the GitHub package registry.
By default, all the jobs will run concurrently in parallel.
But that's not actually what we want here because we want to first build our code before releasing it to the package managers.
We can use the needs keyword to tell GitHub actions to run this job after the previous job is finished.
This can be a really useful technique because in our case here, it allows us to build the code once, and then push it out to 2 different registries without having to rebuild the code.
So that's really useful if you're a library maintainer, but most companies use a lot of other communication tools beyond GitHub, like Slack, Discord, Jira, Trello, and so on.
And in most cases, these tools maintain GitHub apps for you to integrate with their tools directly in GitHub.
When you go to the GitHub marketplace, you'll notice that it's separated by apps and actions.
Actions are reusable pieces of code you use in your own workflow, while apps are fully pre built solutions that don't require you to deploy any code whatsoever.
Because we use Slack for Fireship IO, I'm going to use that as an example.
Let's imagine that I wanted to receive a Slack notification every time a new GitHub issue is posted.
There are a variety of community maintained actions that allow me to do this easily in a workflow.
In this workflow, you can see I set up a trigger for GitHub issues, then use a Slack action along with some configuration variables to have it post messages directly in my Slack channel every time there's a new issue on GitHub.
That's cool and all, but you can also solve this problem using a GitHub app, and it can be installed on your account by simply clicking a few buttons.
The nice thing about a GitHub app is that it can be used across multiple repos simultaneously.
So when you're automating with GitHub Actions, it's a good idea to ask yourself if you want a fully installed app or if you want to build your own workflow with Actions.
I may do a whole separate video on apps because there's a lot of cool things you can do, like automatically analyze code quality, automatically update your dependencies, automatically optimize all your images, and automatically do a whole bunch of other cool stuff.
But now let's shift gears into the final recipe, which is a GitHub action that runs on a specific schedule.
This one happens to be a special treat for Firebase users because it solves a common problem.
How do I export my Firestore data on a regular basis?
Currently, the database doesn't provide automatic backups, so you need to manually export your data in order to reimport it in case of a disaster.
In this recipe, we use the on schedule event and pass it a cron schedule.
If you don't understand how this cron syntax works, don't worry.
Not many people do, but there's an awesome app called the Chrontab Guru that can automatically generate schedules for you.
The schedule in this example runs every night at midnight.
And then in the action itself, we're using an action maintained by Google Cloud Platform.
This action sets up the gcloud CLI in the environment, and then we can use it to run a couple commands to export our Firestore data into a storage bucket.
And that process is now fully automated, so we should hopefully never have to worry about it again.
And check the links in the description for a full write up on how to set up the service account and everything else involved with gcloud.
I'm gonna go ahead and wrap things up there.
Hopefully this video helped you get started with automation in your own project, and let me know what kind of things you're using GitHub Actions for in the comments.
Stay tuned for the giveaway video in a few days, thanks for watching, and and I will see you in the next one.

Speaker 0: One of the best ways to increase productivity in a software project is to automate anything manual or repetitive, and you might be surprised at how easy automation is to implement when you use an awesome tool like GitHub Actions. In today's video, we'll look at 5 different techniques that can improve the quality of your code and make your life more productive through the magic of Dev boss. If you have no idea what terms like Continuous Integration and Delivery mean, you will by the end of this video. And if you choose to follow along with your own project, we will automate the hell out of it. If you're new here, like can subscribe, and grab the full write up from FireShip.

Io. Before we get started, I'd like to take a second to say thank you, because the channel just surpassed 300,000 subscribers. To celebrate that, I have a big giveaway UI plan in the next 100 seconds of code video that everybody can participate in. Stay tuned for that in a couple days pending the apocalypse. We're all gonna die.

Now to get started with today's video, the only thing you really need is a GitHub repository, and the service has a very generous free tier, so don't worry about paying for anything upfront. Now before we jump into these 5 different DevOps recipes, let's answer the question of what is GitHub Actions? Consider a repo one GitHub. There are all kinds of different events that can happen to that repo. Someone might start the repo, send a pull request, or you might merge code into the master branch.

These are examples of events, and any event can trigger an automated workflow. A workflow can spin up 1 or more containers for you in the cloud, then you provide a set of steps or instructions for the container to do something useful for you. GitHub will log the progress of each step and make it very clear if something failed. Now the really cool thing about actions is that instead of writing your own steps from scratch, You can use ones implemented by the community. You can think of each step as a reusable chunk of code, which we call an action.

On GitHub, you'll find hundreds of reusable actions that solve common problems, with each one being its own git repo that you can fork and customize as needed. But I think the best way to get started is to look at some real world examples. A good starting place is continuous integration, And if you have no idea what that term means, make sure to check out my 100 seconds of code video on that topic. The whole idea behind continuous integration or CI is to have developers submit their code to the main code base in small maintainable chunks, usually on a daily basis, and those changes should be automatically tested against the main code base. Let's take a quick tour of the code.

Inside the package JSON, you can see I have a set of scripts here. We use Jest to run automated tests and then build to build the app with Webpack. The app itself is just a simple website that tells you what day of the week it is. Inside the source directory, we have app JS with a JavaScript function that implements that logic. And then we have app dot test dot j s to test that logic.

Feel free to clone this repo if you want to use it as an example, or better yet, use your own project as a starting point because these principles apply to any GitHub repo. When you visit your code on GitHub, you'll notice this actions tab. This is where you can monitor your workflows. When a workflow is triggered, it will give you a log of everything that happened on the server. What we wanna do for continuous integration is have our test suite run anytime there's a pull request to the master branch.

If the test suite fails or if the code fails to build, we should get a red check mark here, automatically telling us not to merge that pull request. But but if everything goes according to plan, we should get a green check mark. Now back in the source code, you can see I have a GitHub directory followed by workflows, and a file called integrate dot yaml. Anything in this workflow's directory will be picked up by GitHub and automatically set up as a workflow in the cloud. The YAML file is where we define the workflow.

Flow. We'll give it a name of node continuous integration, then we need to tell it on which event or events to run. We do that with the on object, And in this case, we want to run it on pull request to the master branch. Now every workflow should have 1 or more jobs. You define them on this job's object, and then first give the job a name.

We'll call this one test pull request. From there, we need to tell the job which VM to run on. I'll run this one on Ubuntu, but you also have the choice of Windows and macOS. Next, we need to give this job a set of steps or instructions that actually build and test our code. We'll first want to get our source code into the virtual machine.

We can do that using an officially maintained action called checkout. That brings your source code into the current working directory, And that means you can run commands like you would from the command line if working on the project locally. But in our case, we also need to set up Node. Js in order to run those commands. So we use the node setup action and then specify the version.

And from there, we're ready to start running our own commands. We first need to install all of our dependencies from npm, And we can do that using the c I command. That's equivalent to npm install, but it does a clean install for your c I server. From there, we'll run our test command to test our code. And then after that, we'll run our build command to make sure the build compiles properly.

Now it's also worth noting that if you have a more complex test suite, like end to end tests with Cypress for example, There's very likely an existing action to set up the test runner for you automatically in the environment. And that's all it takes for the workflow configuration. To start using it, we just need to commit it to the master branch. I'll run git add, git commit, and then git push to push that to the remote repository. Now if you go to the actions tab on GitHub, you'll notice that it's still empty.

That's because we haven't had an actual pull request event to trigger a workflow. So let's go ahead and give our workflow a spin by creating a pull request. I'll go ahead and create a new branch using git checkout with the b flag to automatically move into it. Inside that branch, I'll make some changes to the source code that caused the test to fail. I'll then commit those changes and then push this branch to the remote repo.

When I go back to GitHub, I'll see the option to create a pull request, which I'll go ahead and do. And you'll notice that it indicates how we're running checks or continuous integration tests in the background. If we go to the actions tab, we can see logging for this process running in real time. In this case, the test on the pull request fail, which means we probably shouldn't integrate this code into the main code base. And as the developer who submitted this code, I can look at the logs and realize what I did wrong.

In this case, since I have an open pull request, I can go back into my code and fix it and then push another commit to this branch. GitHub will automatically rerun the workflow because this is an open pull request, and this time around we get green check marks. So that takes care of our continuous integration. Now it's time to move on to the next phase, continuous deployment. At this point, we're confident we have a valid pull request, And when we merge that code into the master branch, we also want to deploy the app to our customers.

So continuous integration is about merging new code into the code base, while continuous deployment is about pushing that code out to your customers. To demonstrate this, I'm going to integrate a third party host, Firebase. And I'd like to give a shout out to Mark Stammaryohan. He put together an awesome guide that will take you through each one of these steps, so make sure to check that out on FireShip IO. We can easily set up hosting locally by running firebase init hosting, then we can push our code to our Firebase hosting account using Firebase deploy.

We can do all this locally because we're authenticated into our Firebase account on our local system. But how do we authenticate a remote CI server to do the same thing? What we'll need to do is share a secret token with GitHub. We can obtain that token from Firebase by running Firebase login c I. This will return us with a token string, which you can think of as an API key or username password combination.

Make sure to keep this value secret. Go ahead and copy the value from the command line, and then head over to your GitHub repo, go to settings, then secrets, and add a new secret. We'll give it a name of Firebase token in all caps, and you'll wanna make sure to use that same name. Then we'll paste in the token and save it. GitHub will automatically encrypt this value for us, and then we can access it securely from our CI server.

In other words, it gives us a way to securely authenticate with Firebase from a GitHub Actions workflow. Now let's go ahead and create another YAML file in the workflows directory. This one we'll call deploy. Instead of running this workflow on a pull request, we'll run it on a push to the master branch. So this workflow will run if we push code directly to the master branch, or if we merge a pull request into it.

Now the job itself looks almost identical to the previous job. We check out the code, set up node, run our build command, but then we need to deploy it. And to do that, we're going to use a third party action called the Firebase action. This action takes care of all the steps required to set up the Firebase CLI on your server. It will run the Firebase command, and then we tell it to use the arguments of deploy only hosting.

Then it's going to be looking for an environment variable of Firebase token. We can access our secret GitHub value by using dollar sign, double braces, followed by secrets dot firebase token. And that's basically all there is to it. We can start using this continuous deployment workflow by pushing it to the master branch. Now if we go back to GitHub and merge that pull request from the previous example, You can see from the login that it automatically builds and deploys our code to Firebase, and the changes should be automatically reflected on the website itself.

And now that we have a basic CICD pipeline, I wanna look at some other cool things you can do with GitHub Actions that you might not realize. Personally, I maintain a few open source projects that are available as libraries through NPM. One of those projects is Svelte Fire. And anytime there's a major code change on the master branch, We cut a new release so developers can use that code in their projects. And every time that happens, I also need to go to the command line, log in to npm, and push that code to the npm registry.

It's kind of annoying and easy to forget, so let's just automate it with GitHub Actions. In this workflow, you'll notice I'm using the release event. That's because not every code change on the master branch requires a new release. For example, if you just fix a typo in the Readme, it doesn't require a whole new release to be pushed out to NPM. PM.

In this recipe, you'll notice we have 2 jobs, 1 for build and one to publish to NPM. And we might want an additional job to publish to the GitHub package registry. By default, all the jobs will run concurrently in parallel. But that's not actually what we want here because we want to first build our code before releasing it to the package managers. We can use the needs keyword to tell GitHub actions to run this job after the previous job is finished.

This can be a really useful technique because in our case here, it allows us to build the code once, and then push it out to 2 different registries without having to rebuild the code. So that's really useful if you're a library maintainer, but most companies use a lot of other communication tools beyond GitHub, like Slack, Discord, Jira, Trello, and so on. And in most cases, these tools maintain GitHub apps for you to integrate with their tools directly in GitHub. When you go to the GitHub marketplace, you'll notice that it's separated by apps and actions. Actions are reusable pieces of code you use in your own workflow, while apps are fully pre built solutions that don't require you to deploy any code whatsoever.

Because we use Slack for Fireship IO, I'm going to use that as an example. Let's imagine that I wanted to receive a Slack notification every time a new GitHub issue is posted. There are a variety of community maintained actions that allow me to do this easily in a workflow. In this workflow, you can see I set up a trigger for GitHub issues, then use a Slack action along with some configuration variables to have it post messages directly in my Slack channel every time there's a new issue on GitHub. That's cool and all, but you can also solve this problem using a GitHub app, and it can be installed on your account by simply clicking a few buttons.

The nice thing about a GitHub app is that it can be used across multiple repos simultaneously. So when you're automating with GitHub Actions, it's a good idea to ask yourself if you want a fully installed app or if you want to build your own workflow with Actions. I may do a whole separate video on apps because there's a lot of cool things you can do, like automatically analyze code quality, automatically update your dependencies, automatically optimize all your images, and automatically do a whole bunch of other cool stuff. But now let's shift gears into the final recipe, which is a GitHub action that runs on a specific schedule. This one happens to be a special treat for Firebase users because it solves a common problem.

How do I export my Firestore data on a regular basis? Currently, the database doesn't provide automatic backups, so you need to manually export your data in order to reimport it in case of a disaster. In this recipe, we use the on schedule event and pass it a cron schedule. If you don't understand how this cron syntax works, don't worry. Not many people do, but there's an awesome app called the Chrontab Guru that can automatically generate schedules for you.

The schedule in this example runs every night at midnight. And then in the action itself, we're using an action maintained by Google Cloud Platform. This action sets up the gcloud CLI in the environment, and then we can use it to run a couple commands to export our Firestore data into a storage bucket. And that process is now fully automated, so we should hopefully never have to worry about it again. And check the links in the description for a full write up on how to set up the service account and everything else involved with gcloud.

I'm gonna go ahead and wrap things up there. Hopefully this video helped you get started with automation in your own project, and let me know what kind of things you're using GitHub Actions for in the comments. Stay tuned for the giveaway video in a few days, thanks for watching, and and I will see you in the next one.
One of the best ways to increase productivity in a software project is to automate anything manual or repetitive, and you might be surprised at how easy automation is to implement when you use an awesome tool like GitHub Actions. In today's video, we'll look at 5 different techniques that can improve the quality of your code and make your life more productive through the magic of Dev boss. If you have no idea what terms like Continuous Integration and Delivery mean, you will by the end of this video.
software
software development
And if you choose to follow along with your own project, we will automate the hell out of it.
If you're new here, like can subscribe, and grab the full write up from FireShip. Io. Before we get started, I'd like to take a second to say thank you, because the channel just surpassed 300,000 subscribers. To celebrate that, I have a big giveaway UI plan in the next 100 seconds of code video that everybody can participate in.
streaming
social media
television
entertainment
Stay tuned for that in a couple days pending the apocalypse. We're all gonna die. Now to get started with today's video, the only thing you really need is a GitHub repository, and the service has a very generous free tier, so don't worry about paying for anything upfront. Now before we jump into these 5 different DevOps recipes, let's answer the question of what is GitHub Actions? Consider a repo one GitHub. There are all kinds of different events that can happen to that repo. Someone might start the repo, send a pull request, or you might merge code into the master branch. These are examples of events, and any event can trigger an automated workflow. A workflow can spin up 1 or more containers for you in the cloud, then you provide a set of steps or instructions for the container to do something useful for you. GitHub will log the progress of each step and make it very clear if something failed. Now the really cool thing about actions is that instead of writing your own steps from scratch, You can use ones implemented by the community. You can think of each step as a reusable chunk of code, which we call an action. On GitHub, you'll find hundreds of reusable actions that solve common problems, with each one being its own git repo that you can fork and customize as needed. But I think the best way to get started is to look at some real world examples. A good starting place is continuous integration, And if you have no idea what that term means, make sure to check out my 100 seconds of code video on that topic. The whole idea behind continuous integration or CI is to have developers submit their code to the main code base in small maintainable chunks, usually on a daily basis, and those changes should be automatically tested against the main code base.
Let's take a quick tour of the code. Inside the package JSON, you can see I have a set of scripts here. We use Jest to run automated tests and then build to build the app with Webpack. The app itself is just a simple website that tells you what day of the week it is.
programming
Inside the source directory, we have app JS with a JavaScript function that implements that logic. And then we have app dot test dot j s to test that logic. Feel free to clone this repo if you want to use it as an example, or better yet, use your own project as a starting point because these principles apply to any GitHub repo. When you visit your code on GitHub, you'll notice this actions tab. This is where you can monitor your workflows. When a workflow is triggered, it will give you a log of everything that happened on the server. What we wanna do for continuous integration is have our test suite run anytime there's a pull request to the master branch. If the test suite fails or if the code fails to build, we should get a red check mark here, automatically telling us not to merge that pull request. But but if everything goes according to plan, we should get a green check mark. Now back in the source code, you can see I have a GitHub directory followed by workflows, and a file called integrate dot yaml. Anything in this workflow's directory will be picked up by GitHub and automatically set up as a workflow in the cloud. The YAML file is where we define the workflow. Flow. We'll give it a name of node continuous integration, then we need to tell it on which event or events to run. We do that with the on object, And in this case, we want to run it on pull request to the master branch. Now every workflow should have 1 or more jobs. You define them on this job's object, and then first give the job a name. We'll call this one test pull request.
From there, we need to tell the job which VM to run on. I'll run this one on Ubuntu, but you also have the choice of Windows and macOS. Next, we need to give this job a set of steps or instructions that actually build and test our code. We'll first want to get our source code into the virtual machine. We can do that using an officially maintained action called checkout. That brings your source code into the current working directory, And that means you can run commands like you would from the command line if working on the project locally.
programming
software
software development
But in our case, we also need to set up Node. Js in order to run those commands. So we use the node setup action and then specify the version. And from there, we're ready to start running our own commands. We first need to install all of our dependencies from npm, And we can do that using the c I command.
That's equivalent to npm install, but it does a clean install for your c I server. From there, we'll run our test command to test our code. And then after that, we'll run our build command to make sure the build compiles properly. Now it's also worth noting that if you have a more complex test suite, like end to end tests with Cypress for example, There's very likely an existing action to set up the test runner for you automatically in the environment.
software development
And that's all it takes for the workflow configuration. To start using it, we just need to commit it to the master branch. I'll run git add, git commit, and then git push to push that to the remote repository. Now if you go to the actions tab on GitHub, you'll notice that it's still empty. That's because we haven't had an actual pull request event to trigger a workflow. So let's go ahead and give our workflow a spin by creating a pull request. I'll go ahead and create a new branch using git checkout with the b flag to automatically move into it. Inside that branch, I'll make some changes to the source code that caused the test to fail. I'll then commit those changes and then push this branch to the remote repo. When I go back to GitHub, I'll see the option to create a pull request, which I'll go ahead and do. And you'll notice that it indicates how we're running checks or continuous integration tests in the background.
If we go to the actions tab, we can see logging for this process running in real time. In this case, the test on the pull request fail, which means we probably shouldn't integrate this code into the main code base. And as the developer who submitted this code, I can look at the logs and realize what I did wrong.
programming
In this case, since I have an open pull request, I can go back into my code and fix it and then push another commit to this branch.
GitHub will automatically rerun the workflow because this is an open pull request, and this time around we get green check marks. So that takes care of our continuous integration. Now it's time to move on to the next phase, continuous deployment. At this point, we're confident we have a valid pull request, And when we merge that code into the master branch, we also want to deploy the app to our customers. So continuous integration is about merging new code into the code base, while continuous deployment is about pushing that code out to your customers.
software development
software
To demonstrate this, I'm going to integrate a third party host, Firebase. And I'd like to give a shout out to Mark Stammaryohan. He put together an awesome guide that will take you through each one of these steps, so make sure to check that out on FireShip IO. We can easily set up hosting locally by running firebase init hosting, then we can push our code to our Firebase hosting account using Firebase deploy. We can do all this locally because we're authenticated into our Firebase account on our local system. But how do we authenticate a remote CI server to do the same thing? What we'll need to do is share a secret token with GitHub. We can obtain that token from Firebase by running Firebase login c I. This will return us with a token string, which you can think of as an API key or username password combination. Make sure to keep this value secret. Go ahead and copy the value from the command line, and then head over to your GitHub repo, go to settings, then secrets, and add a new secret. We'll give it a name of Firebase token in all caps, and you'll wanna make sure to use that same name. Then we'll paste in the token and save it. GitHub will automatically encrypt this value for us, and then we can access it securely from our CI server. In other words, it gives us a way to securely authenticate with Firebase from a GitHub Actions workflow. Now let's go ahead and create another YAML file in the workflows directory. This one we'll call deploy. Instead of running this workflow on a pull request, we'll run it on a push to the master branch. So this workflow will run if we push code directly to the master branch, or if we merge a pull request into it. Now the job itself looks almost identical to the previous job. We check out the code, set up node, run our build command, but then we need to deploy it. And to do that, we're going to use a third party action called the Firebase action. This action takes care of all the steps required to set up the Firebase CLI on your server. It will run the Firebase command, and then we tell it to use the arguments of deploy only hosting. Then it's going to be looking for an environment variable of Firebase token. We can access our secret GitHub value by using dollar sign, double braces, followed by secrets dot firebase token. And that's basically all there is to it. We can start using this continuous deployment workflow by pushing it to the master branch. Now if we go back to GitHub and merge that pull request from the previous example, You can see from the login that it automatically builds and deploys our code to Firebase, and the changes should be automatically reflected on the website itself.
And now that we have a basic CICD pipeline, I wanna look at some other cool things you can do with GitHub Actions that you might not realize. Personally, I maintain a few open source projects that are available as libraries through NPM. One of those projects is Svelte Fire. And anytime there's a major code change on the master branch, We cut a new release so developers can use that code in their projects. And every time that happens, I also need to go to the command line, log in to npm, and push that code to the npm registry.
software development
software
It's kind of annoying and easy to forget, so let's just automate it with GitHub Actions. In this workflow, you'll notice I'm using the release event. That's because not every code change on the master branch requires a new release. For example, if you just fix a typo in the Readme, it doesn't require a whole new release to be pushed out to NPM. PM. In this recipe, you'll notice we have 2 jobs, 1 for build and one to publish to NPM. And we might want an additional job to publish to the GitHub package registry. By default, all the jobs will run concurrently in parallel. But that's not actually what we want here because we want to first build our code before releasing it to the package managers. We can use the needs keyword to tell GitHub actions to run this job after the previous job is finished. This can be a really useful technique because in our case here, it allows us to build the code once, and then push it out to 2 different registries without having to rebuild the code.
So that's really useful if you're a library maintainer, but most companies use a lot of other communication tools beyond GitHub, like Slack, Discord, Jira, Trello, and so on. And in most cases, these tools maintain GitHub apps for you to integrate with their tools directly in GitHub. When you go to the GitHub marketplace, you'll notice that it's separated by apps and actions. Actions are reusable pieces of code you use in your own workflow, while apps are fully pre built solutions that don't require you to deploy any code whatsoever.
software
Because we use Slack for Fireship IO, I'm going to use that as an example. Let's imagine that I wanted to receive a Slack notification every time a new GitHub issue is posted. There are a variety of community maintained actions that allow me to do this easily in a workflow. In this workflow, you can see I set up a trigger for GitHub issues, then use a Slack action along with some configuration variables to have it post messages directly in my Slack channel every time there's a new issue on GitHub. That's cool and all, but you can also solve this problem using a GitHub app, and it can be installed on your account by simply clicking a few buttons.
The nice thing about a GitHub app is that it can be used across multiple repos simultaneously. So when you're automating with GitHub Actions, it's a good idea to ask yourself if you want a fully installed app or if you want to build your own workflow with Actions. I may do a whole separate video on apps because there's a lot of cool things you can do, like automatically analyze code quality, automatically update your dependencies, automatically optimize all your images, and automatically do a whole bunch of other cool stuff. But now let's shift gears into the final recipe, which is a GitHub action that runs on a specific schedule.
software
animation
multimedia
This one happens to be a special treat for Firebase users because it solves a common problem. How do I export my Firestore data on a regular basis? Currently, the database doesn't provide automatic backups, so you need to manually export your data in order to reimport it in case of a disaster. In this recipe, we use the on schedule event and pass it a cron schedule. If you don't understand how this cron syntax works, don't worry. Not many people do, but there's an awesome app called the Chrontab Guru that can automatically generate schedules for you. The schedule in this example runs every night at midnight.
And then in the action itself, we're using an action maintained by Google Cloud Platform. This action sets up the gcloud CLI in the environment, and then we can use it to run a couple commands to export our Firestore data into a storage bucket. And that process is now fully automated, so we should hopefully never have to worry about it again.
google
software
And check the links in the description for a full write up on how to set up the service account and everything else involved with gcloud.
I'm gonna go ahead and wrap things up there. Hopefully this video helped you get started with automation in your own project, and let me know what kind of things you're using GitHub Actions for in the comments. Stay tuned for the giveaway video in a few days, thanks for watching, and and I will see you in the next one.
animation
One of the best ways to increase productivity in a software project is to automate anything manual or repetitive, and you might be surprised at how easy automation is to implement when you use an awesome tool like GitHub Actions. In today's video, we'll look at 5 different techniques that can improve the quality of your code and make your life more productive through the magic of Dev boss. If you have no idea what terms like Continuous Integration and Delivery mean, you will by the end of this video. And if you choose to follow along with your own project, we will automate the hell out of it. If you're new here, like can subscribe, and grab the full write up from FireShip. Io. Before we get started, I'd like to take a second to say thank you, because the channel just surpassed 300,000 subscribers. To celebrate that, I have a big giveaway UI plan in the next 100 seconds of code video that everybody can participate in. Stay tuned for that in a couple days pending the apocalypse. We're all gonna die. Now to get started with today's video, the only thing you really need is a GitHub repository, and the service has a very generous free tier, so don't worry about paying for anything upfront. Now before we jump into these 5 different DevOps recipes, let's answer the question of what is GitHub Actions? Consider a repo one GitHub. There are all kinds of different events that can happen to that repo. Someone might start the repo, send a pull request, or you might merge code into the master branch. These are examples of events, and any event can trigger an automated workflow. A workflow can spin up 1 or more containers for you in the cloud, then you provide a set of steps or instructions for the container to do something useful for you. GitHub will log the progress of each step and make it very clear if something failed. Now the really cool thing about actions is that instead of writing your own steps from scratch, You can use ones implemented by the community. You can think of each step as a reusable chunk of code, which we call an action. On GitHub, you'll find hundreds of reusable actions that solve common problems, with each one being its own git repo that you can fork and customize as needed. But I think the best way to get started is to look at some real world examples. A good starting place is continuous integration, And if you have no idea what that term means, make sure to check out my 100 seconds of code video on that topic. The whole idea behind continuous integration or CI is to have developers submit their code to the main code base in small maintainable chunks, usually on a daily basis, and those changes should be automatically tested against the main code base. Let's take a quick tour of the code. Inside the package JSON, you can see I have a set of scripts here. We use Jest to run automated tests and then build to build the app with Webpack. The app itself is just a simple website that tells you what day of the week it is. Inside the source directory, we have app JS with a JavaScript function that implements that logic. And then we have app dot test dot j s to test that logic. Feel free to clone this repo if you want to use it as an example, or better yet, use your own project as a starting point because these principles apply to any GitHub repo. When you visit your code on GitHub, you'll notice this actions tab. This is where you can monitor your workflows. When a workflow is triggered, it will give you a log of everything that happened on the server. What we wanna do for continuous integration is have our test suite run anytime there's a pull request to the master branch. If the test suite fails or if the code fails to build, we should get a red check mark here, automatically telling us not to merge that pull request. But but if everything goes according to plan, we should get a green check mark. Now back in the source code, you can see I have a GitHub directory followed by workflows, and a file called integrate dot yaml. Anything in this workflow's directory will be picked up by GitHub and automatically set up as a workflow in the cloud. The YAML file is where we define the workflow. Flow. We'll give it a name of node continuous integration, then we need to tell it on which event or events to run. We do that with the on object, And in this case, we want to run it on pull request to the master branch. Now every workflow should have 1 or more jobs. You define them on this job's object, and then first give the job a name. We'll call this one test pull request. From there, we need to tell the job which VM to run on. I'll run this one on Ubuntu, but you also have the choice of Windows and macOS. Next, we need to give this job a set of steps or instructions that actually build and test our code. We'll first want to get our source code into the virtual machine. We can do that using an officially maintained action called checkout. That brings your source code into the current working directory, And that means you can run commands like you would from the command line if working on the project locally. But in our case, we also need to set up Node. Js in order to run those commands. So we use the node setup action and then specify the version. And from there, we're ready to start running our own commands. We first need to install all of our dependencies from npm, And we can do that using the c I command. That's equivalent to npm install, but it does a clean install for your c I server. From there, we'll run our test command to test our code. And then after that, we'll run our build command to make sure the build compiles properly. Now it's also worth noting that if you have a more complex test suite, like end to end tests with Cypress for example, There's very likely an existing action to set up the test runner for you automatically in the environment. And that's all it takes for the workflow configuration. To start using it, we just need to commit it to the master branch. I'll run git add, git commit, and then git push to push that to the remote repository. Now if you go to the actions tab on GitHub, you'll notice that it's still empty. That's because we haven't had an actual pull request event to trigger a workflow. So let's go ahead and give our workflow a spin by creating a pull request. I'll go ahead and create a new branch using git checkout with the b flag to automatically move into it. Inside that branch, I'll make some changes to the source code that caused the test to fail. I'll then commit those changes and then push this branch to the remote repo. When I go back to GitHub, I'll see the option to create a pull request, which I'll go ahead and do. And you'll notice that it indicates how we're running checks or continuous integration tests in the background. If we go to the actions tab, we can see logging for this process running in real time. In this case, the test on the pull request fail, which means we probably shouldn't integrate this code into the main code base. And as the developer who submitted this code, I can look at the logs and realize what I did wrong. In this case, since I have an open pull request, I can go back into my code and fix it and then push another commit to this branch. GitHub will automatically rerun the workflow because this is an open pull request, and this time around we get green check marks. So that takes care of our continuous integration. Now it's time to move on to the next phase, continuous deployment. At this point, we're confident we have a valid pull request, And when we merge that code into the master branch, we also want to deploy the app to our customers. So continuous integration is about merging new code into the code base, while continuous deployment is about pushing that code out to your customers. To demonstrate this, I'm going to integrate a third party host, Firebase. And I'd like to give a shout out to Mark Stammaryohan. He put together an awesome guide that will take you through each one of these steps, so make sure to check that out on FireShip IO. We can easily set up hosting locally by running firebase init hosting, then we can push our code to our Firebase hosting account using Firebase deploy. We can do all this locally because we're authenticated into our Firebase account on our local system. But how do we authenticate a remote CI server to do the same thing? What we'll need to do is share a secret token with GitHub. We can obtain that token from Firebase by running Firebase login c I. This will return us with a token string, which you can think of as an API key or username password combination. Make sure to keep this value secret. Go ahead and copy the value from the command line, and then head over to your GitHub repo, go to settings, then secrets, and add a new secret. We'll give it a name of Firebase token in all caps, and you'll wanna make sure to use that same name. Then we'll paste in the token and save it. GitHub will automatically encrypt this value for us, and then we can access it securely from our CI server. In other words, it gives us a way to securely authenticate with Firebase from a GitHub Actions workflow. Now let's go ahead and create another YAML file in the workflows directory. This one we'll call deploy. Instead of running this workflow on a pull request, we'll run it on a push to the master branch. So this workflow will run if we push code directly to the master branch, or if we merge a pull request into it. Now the job itself looks almost identical to the previous job. We check out the code, set up node, run our build command, but then we need to deploy it. And to do that, we're going to use a third party action called the Firebase action. This action takes care of all the steps required to set up the Firebase CLI on your server. It will run the Firebase command, and then we tell it to use the arguments of deploy only hosting. Then it's going to be looking for an environment variable of Firebase token. We can access our secret GitHub value by using dollar sign, double braces, followed by secrets dot firebase token. And that's basically all there is to it. We can start using this continuous deployment workflow by pushing it to the master branch. Now if we go back to GitHub and merge that pull request from the previous example, You can see from the login that it automatically builds and deploys our code to Firebase, and the changes should be automatically reflected on the website itself. And now that we have a basic CICD pipeline, I wanna look at some other cool things you can do with GitHub Actions that you might not realize. Personally, I maintain a few open source projects that are available as libraries through NPM. One of those projects is Svelte Fire. And anytime there's a major code change on the master branch, We cut a new release so developers can use that code in their projects. And every time that happens, I also need to go to the command line, log in to npm, and push that code to the npm registry. It's kind of annoying and easy to forget, so let's just automate it with GitHub Actions. In this workflow, you'll notice I'm using the release event. That's because not every code change on the master branch requires a new release. For example, if you just fix a typo in the Readme, it doesn't require a whole new release to be pushed out to NPM. PM. In this recipe, you'll notice we have 2 jobs, 1 for build and one to publish to NPM. And we might want an additional job to publish to the GitHub package registry. By default, all the jobs will run concurrently in parallel. But that's not actually what we want here because we want to first build our code before releasing it to the package managers. We can use the needs keyword to tell GitHub actions to run this job after the previous job is finished. This can be a really useful technique because in our case here, it allows us to build the code once, and then push it out to 2 different registries without having to rebuild the code. So that's really useful if you're a library maintainer, but most companies use a lot of other communication tools beyond GitHub, like Slack, Discord, Jira, Trello, and so on. And in most cases, these tools maintain GitHub apps for you to integrate with their tools directly in GitHub. When you go to the GitHub marketplace, you'll notice that it's separated by apps and actions. Actions are reusable pieces of code you use in your own workflow, while apps are fully pre built solutions that don't require you to deploy any code whatsoever. Because we use Slack for Fireship IO, I'm going to use that as an example. Let's imagine that I wanted to receive a Slack notification every time a new GitHub issue is posted. There are a variety of community maintained actions that allow me to do this easily in a workflow. In this workflow, you can see I set up a trigger for GitHub issues, then use a Slack action along with some configuration variables to have it post messages directly in my Slack channel every time there's a new issue on GitHub. That's cool and all, but you can also solve this problem using a GitHub app, and it can be installed on your account by simply clicking a few buttons. The nice thing about a GitHub app is that it can be used across multiple repos simultaneously. So when you're automating with GitHub Actions, it's a good idea to ask yourself if you want a fully installed app or if you want to build your own workflow with Actions. I may do a whole separate video on apps because there's a lot of cool things you can do, like automatically analyze code quality, automatically update your dependencies, automatically optimize all your images, and automatically do a whole bunch of other cool stuff. But now let's shift gears into the final recipe, which is a GitHub action that runs on a specific schedule. This one happens to be a special treat for Firebase users because it solves a common problem. How do I export my Firestore data on a regular basis? Currently, the database doesn't provide automatic backups, so you need to manually export your data in order to reimport it in case of a disaster. In this recipe, we use the on schedule event and pass it a cron schedule. If you don't understand how this cron syntax works, don't worry. Not many people do, but there's an awesome app called the Chrontab Guru that can automatically generate schedules for you. The schedule in this example runs every night at midnight. And then in the action itself, we're using an action maintained by Google Cloud Platform. This action sets up the gcloud CLI in the environment, and then we can use it to run a couple commands to export our Firestore data into a storage bucket. And that process is now fully automated, so we should hopefully never have to worry about it again. And check the links in the description for a full write up on how to set up the service account and everything else involved with gcloud. I'm gonna go ahead and wrap things up there. Hopefully this video helped you get started with automation in your own project, and let me know what kind of things you're using GitHub Actions for in the comments. Stay tuned for the giveaway video in a few days, thanks for watching, and and I will see you in the next one.
One
one
of
of
the
the
best
best
ways
ways
to
to
increase
increase
productivity
productivity
in
in
a
a
software
software
project
project
is
is
to
to
automate
automate
anything
anything
manual
manual
or
or
repetitive,
repetitive
and
and
you
you
might
might
be
be
surprised
surprised
at
at
how
how
easy
easy
automation
automation
is
is
to
to
implement
implement
when
when
you
you
use
use
an
an
awesome
awesome
tool
tool
like
like
GitHub
github
Actions.
actions
In
in
today's
today's
video,
video
we'll
we'll
look
look
at
at
5
5
different
different
techniques
techniques
that
that
can
can
improve
improve
the
the
quality
quality
of
of
your
your
code
code
and
and
make
make
your
your
life
life
more
more
productive
productive
through
through
the
the
magic
magic
of
of
Dev
dev
boss.
boss
If
if
you
you
have
have
no
no
idea
idea
what
what
terms
terms
like
like
Continuous
continuous
Integration
integration
and
and
Delivery
delivery
mean,
mean
you
you
will
will
by
by
the
the
end
end
of
of
this
this
video.
video
And
and
if
if
you
you
choose
choose
to
to
follow
follow
along
along
with
with
your
your
own
own
project,
project
we
we
will
will
automate
automate
the
the
hell
hell
out
out
of
of
it.
it
If
if
you're
you're
new
new
here,
here
like
like
can
can
subscribe,
subscribe
and
and
grab
grab
the
the
full
full
write
write
up
up
from
from
FireShip.
fireship
Io.
io
Before
before
we
we
get
get
started,
started
I'd
i'd
like
like
to
to
take
take
a
a
second
second
to
to
say
say
thank
thank
you,
you
because
because
the
the
channel
channel
just
just
surpassed
surpassed
300,000
300,000
subscribers.
subscribers
To
to
celebrate
celebrate
that,
that
I
i
have
have
a
a
big
big
giveaway
giveaway
UI
ui
plan
plan
in
in
the
the
next
next
100
100
seconds
seconds
of
of
code
code
video
video
that
that
everybody
everybody
can
can
participate
participate
in.
in
Stay
stay
tuned
tuned
for
for
that
that
in
in
a
a
couple
couple
days
days
pending
pending
the
the
apocalypse.
apocalypse
We're
we're
all
all
gonna
gonna
die.
die
Now
now
to
to
get
get
started
started
with
with
today's
today's
video,
video
the
the
only
only
thing
thing
you
you
really
really
need
need
is
is
a
a
GitHub
github
repository,
repository
and
and
the
the
service
service
has
has
a
a
very
very
generous
generous
free
free
tier,
tier
so
so
don't
don't
worry
worry
about
about
paying
paying
for
for
anything
anything
upfront.
upfront
Now
now
before
before
we
we
jump
jump
into
into
these
these
5
5
different
different
DevOps
devops
recipes,
recipes
let's
let's
answer
answer
the
the
question
question
of
of
what
what
is
is
GitHub
github
Actions?
actions
Consider
consider
a
a
repo
repo
one
one
GitHub.
github
There
there
are
are
all
all
kinds
kinds
of
of
different
different
events
events
that
that
can
can
happen
happen
to
to
that
that
repo.
repo
Someone
someone
might
might
start
start
the
the
repo,
repo
send
send
a
a
pull
pull
request,
request
or
or
you
you
might
might
merge
merge
code
code
into
into
the
the
master
master
branch.
branch
These
these
are
are
examples
examples
of
of
events,
events
and
and
any
any
event
event
can
can
trigger
trigger
an
an
automated
automated
workflow.
workflow
A
a
workflow
workflow
can
can
spin
spin
up
up
1
1
or
or
more
more
containers
containers
for
for
you
you
in
in
the
the
cloud,
cloud
then
then
you
you
provide
provide
a
a
set
set
of
of
steps
steps
or
or
instructions
instructions
for
for
the
the
container
container
to
to
do
do
something
something
useful
useful
for
for
you.
you
GitHub
github
will
will
log
log
the
the
progress
progress
of
of
each
each
step
step
and
and
make
make
it
it
very
very
clear
clear
if
if
something
something
failed.
failed
Now
now
the
the
really
really
cool
cool
thing
thing
about
about
actions
actions
is
is
that
that
instead
instead
of
of
writing
writing
your
your
own
own
steps
steps
from
from
scratch,
scratch
You
you
can
can
use
use
ones
ones
implemented
implemented
by
by
the
the
community.
community
You
you
can
can
think
think
of
of
each
each
step
step
as
as
a
a
reusable
reusable
chunk
chunk
of
of
code,
code
which
which
we
we
call
call
an
an
action.
action
On
on
GitHub,
github
you'll
you'll
find
find
hundreds
hundreds
of
of
reusable
reusable
actions
actions
that
that
solve
solve
common
common
problems,
problems
with
with
each
each
one
one
being
being
its
its
own
own
git
git
repo
repo
that
that
you
you
can
can
fork
fork
and
and
customize
customize
as
as
needed.
needed
But
but
I
i
think
think
the
the
best
best
way
way
to
to
get
get
started
started
is
is
to
to
look
look
at
at
some
some
real
real
world
world
examples.
examples
A
a
good
good
starting
starting
place
place
is
is
continuous
continuous
integration,
integration
And
and
if
if
you
you
have
have
no
no
idea
idea
what
what
that
that
term
term
means,
means
make
make
sure
sure
to
to
check
check
out
out
my
my
100
100
seconds
seconds
of
of
code
code
video
video
on
on
that
that
topic.
topic
The
the
whole
whole
idea
idea
behind
behind
continuous
continuous
integration
integration
or
or
CI
ci
is
is
to
to
have
have
developers
developers
submit
submit
their
their
code
code
to
to
the
the
main
main
code
code
base
base
in
in
small
small
maintainable
maintainable
chunks,
chunks
usually
usually
on
on
a
a
daily
daily
basis,
basis
and
and
those
those
changes
changes
should
should
be
be
automatically
automatically
tested
tested
against
against
the
the
main
main
code
code
base.
base
Let's
let's
take
take
a
a
quick
quick
tour
tour
of
of
the
the
code.
code
Inside
inside
the
the
package
package
JSON,
json
you
you
can
can
see
see
I
i
have
have
a
a
set
set
of
of
scripts
scripts
here.
here
We
we
use
use
Jest
jest
to
to
run
run
automated
automated
tests
tests
and
and
then
then
build
build
to
to
build
build
the
the
app
app
with
with
Webpack.
webpack
The
the
app
app
itself
itself
is
is
just
just
a
a
simple
simple
website
website
that
that
tells
tells
you
you
what
what
day
day
of
of
the
the
week
week
it
it
is.
is
Inside
inside
the
the
source
source
directory,
directory
we
we
have
have
app
app
JS
js
with
with
a
a
JavaScript
javascript
function
function
that
that
implements
implements
that
that
logic.
logic
And
and
then
then
we
we
have
have
app
app
dot
dot
test
test
dot
dot
j
j
s
s
to
to
test
test
that
that
logic.
logic
Feel
feel
free
free
to
to
clone
clone
this
this
repo
repo
if
if
you
you
want
want
to
to
use
use
it
it
as
as
an
an
example,
example
or
or
better
better
yet,
yet
use
use
your
your
own
own
project
project
as
as
a
a
starting
starting
point
point
because
because
these
these
principles
principles
apply
apply
to
to
any
any
GitHub
github
repo.
repo
When
when
you
you
visit
visit
your
your
code
code
on
on
GitHub,
github
you'll
you'll
notice
notice
this
this
actions
actions
tab.
tab
This
this
is
is
where
where
you
you
can
can
monitor
monitor
your
your
workflows.
workflows
When
when
a
a
workflow
workflow
is
is
triggered,
triggered
it
it
will
will
give
give
you
you
a
a
log
log
of
of
everything
everything
that
that
happened
happened
on
on
the
the
server.
server
What
what
we
we
wanna
wanna
do
do
for
for
continuous
continuous
integration
integration
is
is
have
have
our
our
test
test
suite
suite
run
run
anytime
anytime
there's
there's
a
a
pull
pull
request
request
to
to
the
the
master
master
branch.
branch
If
if
the
the
test
test
suite
suite
fails
fails
or
or
if
if
the
the
code
code
fails
fails
to
to
build,
build
we
we
should
should
get
get
a
a
red
red
check
check
mark
mark
here,
here
automatically
automatically
telling
telling
us
us
not
not
to
to
merge
merge
that
that
pull
pull
request.
request
But
but
but
but
if
if
everything
everything
goes
goes
according
according
to
to
plan,
plan
we
we
should
should
get
get
a
a
green
green
check
check
mark.
mark
Now
now
back
back
in
in
the
the
source
source
code,
code
you
you
can
can
see
see
I
i
have
have
a
a
GitHub
github
directory
directory
followed
followed
by
by
workflows,
workflows
and
and
a
a
file
file
called
called
integrate
integrate
dot
dot
yaml.
yaml
Anything
anything
in
in
this
this
workflow's
workflow's
directory
directory
will
will
be
be
picked
picked
up
up
by
by
GitHub
github
and
and
automatically
automatically
set
set
up
up
as
as
a
a
workflow
workflow
in
in
the
the
cloud.
cloud
The
the
YAML
yaml
file
file
is
is
where
where
we
we
define
define
the
the
workflow.
workflow
Flow.
flow
We'll
we'll
give
give
it
it
a
a
name
name
of
of
node
node
continuous
continuous
integration,
integration
then
then
we
we
need
need
to
to
tell
tell
it
it
on
on
which
which
event
event
or
or
events
events
to
to
run.
run
We
we
do
do
that
that
with
with
the
the
on
on
object,
object
And
and
in
in
this
this
case,
case
we
we
want
want
to
to
run
run
it
it
on
on
pull
pull
request
request
to
to
the
the
master
master
branch.
branch
Now
now
every
every
workflow
workflow
should
should
have
have
1
1
or
or
more
more
jobs.
jobs
You
you
define
define
them
them
on
on
this
this
job's
job's
object,
object
and
and
then
then
first
first
give
give
the
the
job
job
a
a
name.
name
We'll
we'll
call
call
this
this
one
one
test
test
pull
pull
request.
request
From
from
there,
there
we
we
need
need
to
to
tell
tell
the
the
job
job
which
which
VM
vm
to
to
run
run
on.
on
I'll
i'll
run
run
this
this
one
one
on
on
Ubuntu,
ubuntu
but
but
you
you
also
also
have
have
the
the
choice
choice
of
of
Windows
windows
and
and
macOS.
macos
Next,
next
we
we
need
need
to
to
give
give
this
this
job
job
a
a
set
set
of
of
steps
steps
or
or
instructions
instructions
that
that
actually
actually
build
build
and
and
test
test
our
our
code.
code
We'll
we'll
first
first
want
want
to
to
get
get
our
our
source
source
code
code
into
into
the
the
virtual
virtual
machine.
machine
We
we
can
can
do
do
that
that
using
using
an
an
officially
officially
maintained
maintained
action
action
called
called
checkout.
checkout
That
that
brings
brings
your
your
source
source
code
code
into
into
the
the
current
current
working
working
directory,
directory
And
and
that
that
means
means
you
you
can
can
run
run
commands
commands
like
like
you
you
would
would
from
from
the
the
command
command
line
line
if
if
working
working
on
on
the
the
project
project
locally.
locally
But
but
in
in
our
our
case,
case
we
we
also
also
need
need
to
to
set
set
up
up
Node.
node
Js
js
in
in
order
order
to
to
run
run
those
those
commands.
commands
So
so
we
we
use
use
the
the
node
node
setup
setup
action
action
and
and
then
then
specify
specify
the
the
version.
version
And
and
from
from
there,
there
we're
we're
ready
ready
to
to
start
start
running
running
our
our
own
own
commands.
commands
We
we
first
first
need
need
to
to
install
install
all
all
of
of
our
our
dependencies
dependencies
from
from
npm,
npm
And
and
we
we
can
can
do
do
that
that
using
using
the
the
c
c
I
i
command.
command
That's
that's
equivalent
equivalent
to
to
npm
npm
install,
install
but
but
it
it
does
does
a
a
clean
clean
install
install
for
for
your
your
c
c
I
i
server.
server
From
from
there,
there
we'll
we'll
run
run
our
our
test
test
command
command
to
to
test
test
our
our
code.
code
And
and
then
then
after
after
that,
that
we'll
we'll
run
run
our
our
build
build
command
command
to
to
make
make
sure
sure
the
the
build
build
compiles
compiles
properly.
properly
Now
now
it's
it's
also
also
worth
worth
noting
noting
that
that
if
if
you
you
have
have
a
a
more
more
complex
complex
test
test
suite,
suite
like
like
end
end
to
to
end
end
tests
tests
with
with
Cypress
cypress
for
for
example,
example
There's
there's
very
very
likely
likely
an
an
existing
existing
action
action
to
to
set
set
up
up
the
the
test
test
runner
runner
for
for
you
you
automatically
automatically
in
in
the
the
environment.
environment
And
and
that's
that's
all
all
it
it
takes
takes
for
for
the
the
workflow
workflow
configuration.
configuration
To
to
start
start
using
using
it,
it
we
we
just
just
need
need
to
to
commit
commit
it
it
to
to
the
the
master
master
branch.
branch
I'll
i'll
run
run
git
git
add,
add
git
git
commit,
commit
and
and
then
then
git
git
push
push
to
to
push
push
that
that
to
to
the
the
remote
remote
repository.
repository
Now
now
if
if
you
you
go
go
to
to
the
the
actions
actions
tab
tab
on
on
GitHub,
github
you'll
you'll
notice
notice
that
that
it's
it's
still
still
empty.
empty
That's
that's
because
because
we
we
haven't
haven't
had
had
an
an
actual
actual
pull
pull
request
request
event
event
to
to
trigger
trigger
a
a
workflow.
workflow
So
so
let's
let's
go
go
ahead
ahead
and
and
give
give
our
our
workflow
workflow
a
a
spin
spin
by
by
creating
creating
a
a
pull
pull
request.
request
I'll
i'll
go
go
ahead
ahead
and
and
create
create
a
a
new
new
branch
branch
using
using
git
git
checkout
checkout
with
with
the
the
b
b
flag
flag
to
to
automatically
automatically
move
move
into
into
it.
it
Inside
inside
that
that
branch,
branch
I'll
i'll
make
make
some
some
changes
changes
to
to
the
the
source
source
code
code
that
that
caused
caused
the
the
test
test
to
to
fail.
fail
I'll
i'll
then
then
commit
commit
those
those
changes
changes
and
and
then
then
push
push
this
this
branch
branch
to
to
the
the
remote
remote
repo.
repo
When
when
I
i
go
go
back
back
to
to
GitHub,
github
I'll
i'll
see
see
the
the
option
option
to
to
create
create
a
a
pull
pull
request,
request
which
which
I'll
i'll
go
go
ahead
ahead
and
and
do.
do
And
and
you'll
you'll
notice
notice
that
that
it
it
indicates
indicates
how
how
we're
we're
running
running
checks
checks
or
or
continuous
continuous
integration
integration
tests
tests
in
in
the
the
background.
background
If
if
we
we
go
go
to
to
the
the
actions
actions
tab,
tab
we
we
can
can
see
see
logging
logging
for
for
this
this
process
process
running
running
in
in
real
real
time.
time
In
in
this
this
case,
case
the
the
test
test
on
on
the
the
pull
pull
request
request
fail,
fail
which
which
means
means
we
we
probably
probably
shouldn't
shouldn't
integrate
integrate
this
this
code
code
into
into
the
the
main
main
code
code
base.
base
And
and
as
as
the
the
developer
developer
who
who
submitted
submitted
this
this
code,
code
I
i
can
can
look
look
at
at
the
the
logs
logs
and
and
realize
realize
what
what
I
i
did
did
wrong.
wrong
In
in
this
this
case,
case
since
since
I
i
have
have
an
an
open
open
pull
pull
request,
request
I
i
can
can
go
go
back
back
into
into
my
my
code
code
and
and
fix
fix
it
it
and
and
then
then
push
push
another
another
commit
commit
to
to
this
this
branch.
branch
GitHub
github
will
will
automatically
automatically
rerun
rerun
the
the
workflow
workflow
because
because
this
this
is
is
an
an
open
open
pull
pull
request,
request
and
and
this
this
time
time
around
around
we
we
get
get
green
green
check
check
marks.
marks
So
so
that
that
takes
takes
care
care
of
of
our
our
continuous
continuous
integration.
integration
Now
now
it's
it's
time
time
to
to
move
move
on
on
to
to
the
the
next
next
phase,
phase
continuous
continuous
deployment.
deployment
At
at
this
this
point,
point
we're
we're
confident
confident
we
we
have
have
a
a
valid
valid
pull
pull
request,
request
And
and
when
when
we
we
merge
merge
that
that
code
code
into
into
the
the
master
master
branch,
branch
we
we
also
also
want
want
to
to
deploy
deploy
the
the
app
app
to
to
our
our
customers.
customers
So
so
continuous
continuous
integration
integration
is
is
about
about
merging
merging
new
new
code
code
into
into
the
the
code
code
base,
base
while
while
continuous
continuous
deployment
deployment
is
is
about
about
pushing
pushing
that
that
code
code
out
out
to
to
your
your
customers.
customers
To
to
demonstrate
demonstrate
this,
this
I'm
i'm
going
going
to
to
integrate
integrate
a
a
third
third
party
party
host,
host
Firebase.
firebase
And
and
I'd
i'd
like
like
to
to
give
give
a
a
shout
shout
out
out
to
to
Mark
mark
Stammaryohan.
stammaryohan
He
he
put
put
together
together
an
an
awesome
awesome
guide
guide
that
that
will
will
take
take
you
you
through
through
each
each
one
one
of
of
these
these
steps,
steps
so
so
make
make
sure
sure
to
to
check
check
that
that
out
out
on
on
FireShip
fireship
IO.
io
We
we
can
can
easily
easily
set
set
up
up
hosting
hosting
locally
locally
by
by
running
running
firebase
firebase
init
init
hosting,
hosting
then
then
we
we
can
can
push
push
our
our
code
code
to
to
our
our
Firebase
firebase
hosting
hosting
account
account
using
using
Firebase
firebase
deploy.
deploy
We
we
can
can
do
do
all
all
this
this
locally
locally
because
because
we're
we're
authenticated
authenticated
into
into
our
our
Firebase
firebase
account
account
on
on
our
our
local
local
system.
system
But
but
how
how
do
do
we
we
authenticate
authenticate
a
a
remote
remote
CI
ci
server
server
to
to
do
do
the
the
same
same
thing?
thing
What
what
we'll
we'll
need
need
to
to
do
do
is
is
share
share
a
a
secret
secret
token
token
with
with
GitHub.
github
We
we
can
can
obtain
obtain
that
that
token
token
from
from
Firebase
firebase
by
by
running
running
Firebase
firebase
login
login
c
c
I.
i
This
this
will
will
return
return
us
us
with
with
a
a
token
token
string,
string
which
which
you
you
can
can
think
think
of
of
as
as
an
an
API
api
key
key
or
or
username
username
password
password
combination.
combination
Make
make
sure
sure
to
to
keep
keep
this
this
value
value
secret.
secret
Go
go
ahead
ahead
and
and
copy
copy
the
the
value
value
from
from
the
the
command
command
line,
line
and
and
then
then
head
head
over
over
to
to
your
your
GitHub
github
repo,
repo
go
go
to
to
settings,
settings
then
then
secrets,
secrets
and
and
add
add
a
a
new
new
secret.
secret
We'll
we'll
give
give
it
it
a
a
name
name
of
of
Firebase
firebase
token
token
in
in
all
all
caps,
caps
and
and
you'll
you'll
wanna
wanna
make
make
sure
sure
to
to
use
use
that
that
same
same
name.
name
Then
then
we'll
we'll
paste
paste
in
in
the
the
token
token
and
and
save
save
it.
it
GitHub
github
will
will
automatically
automatically
encrypt
encrypt
this
this
value
value
for
for
us,
us
and
and
then
then
we
we
can
can
access
access
it
it
securely
securely
from
from
our
our
CI
ci
server.
server
In
in
other
other
words,
words
it
it
gives
gives
us
us
a
a
way
way
to
to
securely
securely
authenticate
authenticate
with
with
Firebase
firebase
from
from
a
a
GitHub
github
Actions
actions
workflow.
workflow
Now
now
let's
let's
go
go
ahead
ahead
and
and
create
create
another
another
YAML
yaml
file
file
in
in
the
the
workflows
workflows
directory.
directory
This
this
one
one
we'll
we'll
call
call
deploy.
deploy
Instead
instead
of
of
running
running
this
this
workflow
workflow
on
on
a
a
pull
pull
request,
request
we'll
we'll
run
run
it
it
on
on
a
a
push
push
to
to
the
the
master
master
branch.
branch
So
so
this
this
workflow
workflow
will
will
run
run
if
if
we
we
push
push
code
code
directly
directly
to
to
the
the
master
master
branch,
branch
or
or
if
if
we
we
merge
merge
a
a
pull
pull
request
request
into
into
it.
it
Now
now
the
the
job
job
itself
itself
looks
looks
almost
almost
identical
identical
to
to
the
the
previous
previous
job.
job
We
we
check
check
out
out
the
the
code,
code
set
set
up
up
node,
node
run
run
our
our
build
build
command,
command
but
but
then
then
we
we
need
need
to
to
deploy
deploy
it.
it
And
and
to
to
do
do
that,
that
we're
we're
going
going
to
to
use
use
a
a
third
third
party
party
action
action
called
called
the
the
Firebase
firebase
action.
action
This
this
action
action
takes
takes
care
care
of
of
all
all
the
the
steps
steps
required
required
to
to
set
set
up
up
the
the
Firebase
firebase
CLI
cli
on
on
your
your
server.
server
It
it
will
will
run
run
the
the
Firebase
firebase
command,
command
and
and
then
then
we
we
tell
tell
it
it
to
to
use
use
the
the
arguments
arguments
of
of
deploy
deploy
only
only
hosting.
hosting
Then
then
it's
it's
going
going
to
to
be
be
looking
looking
for
for
an
an
environment
environment
variable
variable
of
of
Firebase
firebase
token.
token
We
we
can
can
access
access
our
our
secret
secret
GitHub
github
value
value
by
by
using
using
dollar
dollar
sign,
sign
double
double
braces,
braces
followed
followed
by
by
secrets
secrets
dot
dot
firebase
firebase
token.
token
And
and
that's
that's
basically
basically
all
all
there
there
is
is
to
to
it.
it
We
we
can
can
start
start
using
using
this
this
continuous
continuous
deployment
deployment
workflow
workflow
by
by
pushing
pushing
it
it
to
to
the
the
master
master
branch.
branch
Now
now
if
if
we
we
go
go
back
back
to
to
GitHub
github
and
and
merge
merge
that
that
pull
pull
request
request
from
from
the
the
previous
previous
example,
example
You
you
can
can
see
see
from
from
the
the
login
login
that
that
it
it
automatically
automatically
builds
builds
and
and
deploys
deploys
our
our
code
code
to
to
Firebase,
firebase
and
and
the
the
changes
changes
should
should
be
be
automatically
automatically
reflected
reflected
on
on
the
the
website
website
itself.
itself
And
and
now
now
that
that
we
we
have
have
a
a
basic
basic
CICD
cicd
pipeline,
pipeline
I
i
wanna
wanna
look
look
at
at
some
some
other
other
cool
cool
things
things
you
you
can
can
do
do
with
with
GitHub
github
Actions
actions
that
that
you
you
might
might
not
not
realize.
realize
Personally,
personally
I
i
maintain
maintain
a
a
few
few
open
open
source
source
projects
projects
that
that
are
are
available
available
as
as
libraries
libraries
through
through
NPM.
npm
One
one
of
of
those
those
projects
projects
is
is
Svelte
svelte
Fire.
fire
And
and
anytime
anytime
there's
there's
a
a
major
major
code
code
change
change
on
on
the
the
master
master
branch,
branch
We
we
cut
cut
a
a
new
new
release
release
so
so
developers
developers
can
can
use
use
that
that
code
code
in
in
their
their
projects.
projects
And
and
every
every
time
time
that
that
happens,
happens
I
i
also
also
need
need
to
to
go
go
to
to
the
the
command
command
line,
line
log
log
in
in
to
to
npm,
npm
and
and
push
push
that
that
code
code
to
to
the
the
npm
npm
registry.
registry
It's
it's
kind
kind
of
of
annoying
annoying
and
and
easy
easy
to
to
forget,
forget
so
so
let's
let's
just
just
automate
automate
it
it
with
with
GitHub
github
Actions.
actions
In
in
this
this
workflow,
workflow
you'll
you'll
notice
notice
I'm
i'm
using
using
the
the
release
release
event.
event
That's
that's
because
because
not
not
every
every
code
code
change
change
on
on
the
the
master
master
branch
branch
requires
requires
a
a
new
new
release.
release
For
for
example,
example
if
if
you
you
just
just
fix
fix
a
a
typo
typo
in
in
the
the
Readme,
readme
it
it
doesn't
doesn't
require
require
a
a
whole
whole
new
new
release
release
to
to
be
be
pushed
pushed
out
out
to
to
NPM.
npm
PM.
pm
In
in
this
this
recipe,
recipe
you'll
you'll
notice
notice
we
we
have
have
2
2
jobs,
jobs
1
1
for
for
build
build
and
and
one
one
to
to
publish
publish
to
to
NPM.
npm
And
and
we
we
might
might
want
want
an
an
additional
additional
job
job
to
to
publish
publish
to
to
the
the
GitHub
github
package
package
registry.
registry
By
by
default,
default
all
all
the
the
jobs
jobs
will
will
run
run
concurrently
concurrently
in
in
parallel.
parallel
But
but
that's
that's
not
not
actually
actually
what
what
we
we
want
want
here
here
because
because
we
we
want
want
to
to
first
first
build
build
our
our
code
code
before
before
releasing
releasing
it
it
to
to
the
the
package
package
managers.
managers
We
we
can
can
use
use
the
the
needs
needs
keyword
keyword
to
to
tell
tell
GitHub
github
actions
actions
to
to
run
run
this
this
job
job
after
after
the
the
previous
previous
job
job
is
is
finished.
finished
This
this
can
can
be
be
a
a
really
really
useful
useful
technique
technique
because
because
in
in
our
our
case
case
here,
here
it
it
allows
allows
us
us
to
to
build
build
the
the
code
code
once,
once
and
and
then
then
push
push
it
it
out
out
to
to
2
2
different
different
registries
registries
without
without
having
having
to
to
rebuild
rebuild
the
the
code.
code
So
so
that's
that's
really
really
useful
useful
if
if
you're
you're
a
a
library
library
maintainer,
maintainer
but
but
most
most
companies
companies
use
use
a
a
lot
lot
of
of
other
other
communication
communication
tools
tools
beyond
beyond
GitHub,
github
like
like
Slack,
slack
Discord,
discord
Jira,
jira
Trello,
trello
and
and
so
so
on.
on
And
and
in
in
most
most
cases,
cases
these
these
tools
tools
maintain
maintain
GitHub
github
apps
apps
for
for
you
you
to
to
integrate
integrate
with
with
their
their
tools
tools
directly
directly
in
in
GitHub.
github
When
when
you
you
go
go
to
to
the
the
GitHub
github
marketplace,
marketplace
you'll
you'll
notice
notice
that
that
it's
it's
separated
separated
by
by
apps
apps
and
and
actions.
actions
Actions
actions
are
are
reusable
reusable
pieces
pieces
of
of
code
code
you
you
use
use
in
in
your
your
own
own
workflow,
workflow
while
while
apps
apps
are
are
fully
fully
pre
pre
built
built
solutions
solutions
that
that
don't
don't
require
require
you
you
to
to
deploy
deploy
any
any
code
code
whatsoever.
whatsoever
Because
because
we
we
use
use
Slack
slack
for
for
Fireship
fireship
IO,
io
I'm
i'm
going
going
to
to
use
use
that
that
as
as
an
an
example.
example
Let's
let's
imagine
imagine
that
that
I
i
wanted
wanted
to
to
receive
receive
a
a
Slack
slack
notification
notification
every
every
time
time
a
a
new
new
GitHub
github
issue
issue
is
is
posted.
posted
There
there
are
are
a
a
variety
variety
of
of
community
community
maintained
maintained
actions
actions
that
that
allow
allow
me
me
to
to
do
do
this
this
easily
easily
in
in
a
a
workflow.
workflow
In
in
this
this
workflow,
workflow
you
you
can
can
see
see
I
i
set
set
up
up
a
a
trigger
trigger
for
for
GitHub
github
issues,
issues
then
then
use
use
a
a
Slack
slack
action
action
along
along
with
with
some
some
configuration
configuration
variables
variables
to
to
have
have
it
it
post
post
messages
messages
directly
directly
in
in
my
my
Slack
slack
channel
channel
every
every
time
time
there's
there's
a
a
new
new
issue
issue
on
on
GitHub.
github
That's
that's
cool
cool
and
and
all,
all
but
but
you
you
can
can
also
also
solve
solve
this
this
problem
problem
using
using
a
a
GitHub
github
app,
app
and
and
it
it
can
can
be
be
installed
installed
on
on
your
your
account
account
by
by
simply
simply
clicking
clicking
a
a
few
few
buttons.
buttons
The
the
nice
nice
thing
thing
about
about
a
a
GitHub
github
app
app
is
is
that
that
it
it
can
can
be
be
used
used
across
across
multiple
multiple
repos
repos
simultaneously.
simultaneously
So
so
when
when
you're
you're
automating
automating
with
with
GitHub
github
Actions,
actions
it's
it's
a
a
good
good
idea
idea
to
to
ask
ask
yourself
yourself
if
if
you
you
want
want
a
a
fully
fully
installed
installed
app
app
or
or
if
if
you
you
want
want
to
to
build
build
your
your
own
own
workflow
workflow
with
with
Actions.
actions
I
i
may
may
do
do
a
a
whole
whole
separate
separate
video
video
on
on
apps
apps
because
because
there's
there's
a
a
lot
lot
of
of
cool
cool
things
things
you
you
can
can
do,
do
like
like
automatically
automatically
analyze
analyze
code
code
quality,
quality
automatically
automatically
update
update
your
your
dependencies,
dependencies
automatically
automatically
optimize
optimize
all
all
your
your
images,
images
and
and
automatically
automatically
do
do
a
a
whole
whole
bunch
bunch
of
of
other
other
cool
cool
stuff.
stuff
But
but
now
now
let's
let's
shift
shift
gears
gears
into
into
the
the
final
final
recipe,
recipe
which
which
is
is
a
a
GitHub
github
action
action
that
that
runs
runs
on
on
a
a
specific
specific
schedule.
schedule
This
this
one
one
happens
happens
to
to
be
be
a
a
special
special
treat
treat
for
for
Firebase
firebase
users
users
because
because
it
it
solves
solves
a
a
common
common
problem.
problem
How
how
do
do
I
i
export
export
my
my
Firestore
firestore
data
data
on
on
a
a
regular
regular
basis?
basis
Currently,
currently
the
the
database
database
doesn't
doesn't
provide
provide
automatic
automatic
backups,
backups
so
so
you
you
need
need
to
to
manually
manually
export
export
your
your
data
data
in
in
order
order
to
to
reimport
reimport
it
it
in
in
case
case
of
of
a
a
disaster.
disaster
In
in
this
this
recipe,
recipe
we
we
use
use
the
the
on
on
schedule
schedule
event
event
and
and
pass
pass
it
it
a
a
cron
cron
schedule.
schedule
If
if
you
you
don't
don't
understand
understand
how
how
this
this
cron
cron
syntax
syntax
works,
works
don't
don't
worry.
worry
Not
not
many
many
people
people
do,
do
but
but
there's
there's
an
an
awesome
awesome
app
app
called
called
the
the
Chrontab
chrontab
Guru
guru
that
that
can
can
automatically
automatically
generate
generate
schedules
schedules
for
for
you.
you
The
the
schedule
schedule
in
in
this
this
example
example
runs
runs
every
every
night
night
at
at
midnight.
midnight
And
and
then
then
in
in
the
the
action
action
itself,
itself
we're
we're
using
using
an
an
action
action
maintained
maintained
by
by
Google
google
Cloud
cloud
Platform.
platform
This
this
action
action
sets
sets
up
up
the
the
gcloud
gcloud
CLI
cli
in
in
the
the
environment,
environment
and
and
then
then
we
we
can
can
use
use
it
it
to
to
run
run
a
a
couple
couple
commands
commands
to
to
export
export
our
our
Firestore
firestore
data
data
into
into
a
a
storage
storage
bucket.
bucket
And
and
that
that
process
process
is
is
now
now
fully
fully
automated,
automated
so
so
we
we
should
should
hopefully
hopefully
never
never
have
have
to
to
worry
worry
about
about
it
it
again.
again
And
and
check
check
the
the
links
links
in
in
the
the
description
description
for
for
a
a
full
full
write
write
up
up
on
on
how
how
to
to
set
set
up
up
the
the
service
service
account
account
and
and
everything
everything
else
else
involved
involved
with
with
gcloud.
gcloud
I'm
i'm
gonna
gonna
go
go
ahead
ahead
and
and
wrap
wrap
things
things
up
up
there.
there
Hopefully
hopefully
this
this
video
video
helped
helped
you
you
get
get
started
started
with
with
automation
automation
in
in
your
your
own
own
project,
project
and
and
let
let
me
me
know
know
what
what
kind
kind
of
of
things
things
you're
you're
using
using
GitHub
github
Actions
actions
for
for
in
in
the
the
comments.
comments
Stay
stay
tuned
tuned
for
for
the
the
giveaway
giveaway
video
video
in
in
a
a
few
few
days,
days
thanks
thanks
for
for
watching,
watching
and
and
and
and
I
i
will
will
see
see
you
you
in
in
the
the
next
next
one.
one
success
The speakers discuss automation and GitHub Workflows in a software project, highlighting their benefits for productivity and automation of manual or repetitive tasks. They also discuss the process of creating a new branch, deploying code locally, using a third party host, and setting up a trigger for job automation. A guide for developers is provided for future projects, including open source projects available through NPM. A tool called GitHub argue allows for automatic build and push of code to Azure, and setting up a trigger for job automation is discussed.
5 Ways to DevOps-ify your App - Github Actions Tutorial
One of the best ways to increase productivity in a software project is to automate anything manual or repetitive, and you might be surprised at how easy automation is to implement when you use an awesome tool like GitHub Actions. In today's video, we'll look at 5 different techniques that can improve the quality of your code and make your life more productive through the magic of Dev boss. If you have no idea what terms like Continuous Integration and Delivery mean, you will by the end of this video. And if you choose to follow along with your own project, we will automate the hell out of it. If you're new here, like can subscribe, and grab the full write up from FireShip. Io. Before we get started, I'd like to take a second to say thank you, because the channel just surpassed 300,000 subscribers. To celebrate that, I have a big giveaway UI plan in the next 100 seconds of code video that everybody can participate in. Stay tuned for that in a couple days pending the apocalypse. We're all gonna die. Now to get started with today's video, the only thing you really need is a GitHub repository, and the service has a very generous free tier, so don't worry about paying for anything upfront. Now before we jump into these 5 different DevOps recipes, let's answer the question of what is GitHub Actions? Consider a repo one GitHub. There are all kinds of different events that can happen to that repo. Someone might start the repo, send a pull request, or you might merge code into the master branch. These are examples of events, and any event can trigger an automated workflow. A workflow can spin up 1 or more containers for you in the cloud, then you provide a set of steps or instructions for the container to do something useful for you. GitHub will log the progress of each step and make it very clear if something failed. Now the really cool thing about actions is that instead of writing your own steps from scratch, You can use ones implemented by the community. You can think of each step as a reusable chunk of code, which we call an action. On GitHub, you'll find hundreds of reusable actions that solve common problems, with each one being its own git repo that you can fork and customize as needed. But I think the best way to get started is to look at some real world examples. A good starting place is continuous integration, And if you have no idea what that term means, make sure to check out my 100 seconds of code video on that topic. The whole idea behind continuous integration or CI is to have developers submit their code to the main code base in small maintainable chunks, usually on a daily basis, and those changes should be automatically tested against the main code base. Let's take a quick tour of the code. Inside the package JSON, you can see I have a set of scripts here. We use Jest to run automated tests and then build to build the app with Webpack. The app itself is just a simple website that tells you what day of the week it is. Inside the source directory, we have app JS with a JavaScript function that implements that logic. And then we have app dot test dot j s to test that logic. Feel free to clone this repo if you want to use it as an example, or better yet, use your own project as a starting point because these principles apply to any GitHub repo. When you visit your code on GitHub, you'll notice this actions tab. This is where you can monitor your workflows. When a workflow is triggered, it will give you a log of everything that happened on the server. What we wanna do for continuous integration is have our test suite run anytime there's a pull request to the master branch. If the test suite fails or if the code fails to build, we should get a red check mark here, automatically telling us not to merge that pull request. But but if everything goes according to plan, we should get a green check mark. Now back in the source code, you can see I have a GitHub directory followed by workflows, and a file called integrate dot yaml. Anything in this workflow's directory will be picked up by GitHub and automatically set up as a workflow in the cloud. The YAML file is where we define the workflow. Flow. We'll give it a name of node continuous integration, then we need to tell it on which event or events to run. We do that with the on object, And in this case, we want to run it on pull request to the master branch. Now every workflow should have 1 or more jobs. You define them on this job's object, and then first give the job a name. We'll call this one test pull request. From there, we need to tell the job which VM to run on. I'll run this one on Ubuntu, but you also have the choice of Windows and macOS. Next, we need to give this job a set of steps or instructions that actually build and test our code. We'll first want to get our source code into the virtual machine. We can do that using an officially maintained action called checkout. That brings your source code into the current working directory, And that means you can run commands like you would from the command line if working on the project locally. But in our case, we also need to set up Node. Js in order to run those commands. So we use the node setup action and then specify the version. And from there, we're ready to start running our own commands. We first need to install all of our dependencies from npm, And we can do that using the c I command. That's equivalent to npm install, but it does a clean install for your c I server. From there, we'll run our test command to test our code. And then after that, we'll run our build command to make sure the build compiles properly. Now it's also worth noting that if you have a more complex test suite, like end to end tests with Cypress for example, There's very likely an existing action to set up the test runner for you automatically in the environment. And that's all it takes for the workflow configuration. To start using it, we just need to commit it to the master branch. I'll run git add, git commit, and then git push to push that to the remote repository. Now if you go to the actions tab on GitHub, you'll notice that it's still empty. That's because we haven't had an actual pull request event to trigger a workflow. So let's go ahead and give our workflow a spin by creating a pull request. I'll go ahead and create a new branch using git checkout with the b flag to automatically move into it. Inside that branch, I'll make some changes to the source code that caused the test to fail. I'll then commit those changes and then push this branch to the remote repo. When I go back to GitHub, I'll see the option to create a pull request, which I'll go ahead and do. And you'll notice that it indicates how we're running checks or continuous integration tests in the background. If we go to the actions tab, we can see logging for this process running in real time. In this case, the test on the pull request fail, which means we probably shouldn't integrate this code into the main code base. And as the developer who submitted this code, I can look at the logs and realize what I did wrong. In this case, since I have an open pull request, I can go back into my code and fix it and then push another commit to this branch. GitHub will automatically rerun the workflow because this is an open pull request, and this time around we get green check marks. So that takes care of our continuous integration. Now it's time to move on to the next phase, continuous deployment. At this point, we're confident we have a valid pull request, And when we merge that code into the master branch, we also want to deploy the app to our customers. So continuous integration is about merging new code into the code base, while continuous deployment is about pushing that code out to your customers. To demonstrate this, I'm going to integrate a third party host, Firebase. And I'd like to give a shout out to Mark Stammaryohan. He put together an awesome guide that will take you through each one of these steps, so make sure to check that out on FireShip IO. We can easily set up hosting locally by running firebase init hosting, then we can push our code to our Firebase hosting account using Firebase deploy. We can do all this locally because we're authenticated into our Firebase account on our local system. But how do we authenticate a remote CI server to do the same thing? What we'll need to do is share a secret token with GitHub. We can obtain that token from Firebase by running Firebase login c I. This will return us with a token string, which you can think of as an API key or username password combination. Make sure to keep this value secret. Go ahead and copy the value from the command line, and then head over to your GitHub repo, go to settings, then secrets, and add a new secret. We'll give it a name of Firebase token in all caps, and you'll wanna make sure to use that same name. Then we'll paste in the token and save it. GitHub will automatically encrypt this value for us, and then we can access it securely from our CI server. In other words, it gives us a way to securely authenticate with Firebase from a GitHub Actions workflow. Now let's go ahead and create another YAML file in the workflows directory. This one we'll call deploy. Instead of running this workflow on a pull request, we'll run it on a push to the master branch. So this workflow will run if we push code directly to the master branch, or if we merge a pull request into it. Now the job itself looks almost identical to the previous job. We check out the code, set up node, run our build command, but then we need to deploy it. And to do that, we're going to use a third party action called the Firebase action. This action takes care of all the steps required to set up the Firebase CLI on your server. It will run the Firebase command, and then we tell it to use the arguments of deploy only hosting. Then it's going to be looking for an environment variable of Firebase token. We can access our secret GitHub value by using dollar sign, double braces, followed by secrets dot firebase token. And that's basically all there is to it. We can start using this continuous deployment workflow by pushing it to the master branch. Now if we go back to GitHub and merge that pull request from the previous example, You can see from the login that it automatically builds and deploys our code to Firebase, and the changes should be automatically reflected on the website itself. And now that we have a basic CICD pipeline, I wanna look at some other cool things you can do with GitHub Actions that you might not realize. Personally, I maintain a few open source projects that are available as libraries through NPM. One of those projects is Svelte Fire. And anytime there's a major code change on the master branch, We cut a new release so developers can use that code in their projects. And every time that happens, I also need to go to the command line, log in to npm, and push that code to the npm registry. It's kind of annoying and easy to forget, so let's just automate it with GitHub Actions. In this workflow, you'll notice I'm using the release event. That's because not every code change on the master branch requires a new release. For example, if you just fix a typo in the Readme, it doesn't require a whole new release to be pushed out to NPM. PM. In this recipe, you'll notice we have 2 jobs, 1 for build and one to publish to NPM. And we might want an additional job to publish to the GitHub package registry. By default, all the jobs will run concurrently in parallel. But that's not actually what we want here because we want to first build our code before releasing it to the package managers. We can use the needs keyword to tell GitHub actions to run this job after the previous job is finished. This can be a really useful technique because in our case here, it allows us to build the code once, and then push it out to 2 different registries without having to rebuild the code. So that's really useful if you're a library maintainer, but most companies use a lot of other communication tools beyond GitHub, like Slack, Discord, Jira, Trello, and so on. And in most cases, these tools maintain GitHub apps for you to integrate with their tools directly in GitHub. When you go to the GitHub marketplace, you'll notice that it's separated by apps and actions. Actions are reusable pieces of code you use in your own workflow, while apps are fully pre built solutions that don't require you to deploy any code whatsoever. Because we use Slack for Fireship IO, I'm going to use that as an example. Let's imagine that I wanted to receive a Slack notification every time a new GitHub issue is posted. There are a variety of community maintained actions that allow me to do this easily in a workflow. In this workflow, you can see I set up a trigger for GitHub issues, then use a Slack action along with some configuration variables to have it post messages directly in my Slack channel every time there's a new issue on GitHub. That's cool and all, but you can also solve this problem using a GitHub app, and it can be installed on your account by simply clicking a few buttons. The nice thing about a GitHub app is that it can be used across multiple repos simultaneously. So when you're automating with GitHub Actions, it's a good idea to ask yourself if you want a fully installed app or if you want to build your own workflow with Actions. I may do a whole separate video on apps because there's a lot of cool things you can do, like automatically analyze code quality, automatically update your dependencies, automatically optimize all your images, and automatically do a whole bunch of other cool stuff. But now let's shift gears into the final recipe, which is a GitHub action that runs on a specific schedule. This one happens to be a special treat for Firebase users because it solves a common problem. How do I export my Firestore data on a regular basis? Currently, the database doesn't provide automatic backups, so you need to manually export your data in order to reimport it in case of a disaster. In this recipe, we use the on schedule event and pass it a cron schedule. If you don't understand how this cron syntax works, don't worry. Not many people do, but there's an awesome app called the Chrontab Guru that can automatically generate schedules for you. The schedule in this example runs every night at midnight. And then in the action itself, we're using an action maintained by Google Cloud Platform. This action sets up the gcloud CLI in the environment, and then we can use it to run a couple commands to export our Firestore data into a storage bucket. And that process is now fully automated, so we should hopefully never have to worry about it again. And check the links in the description for a full write up on how to set up the service account and everything else involved with gcloud. I'm gonna go ahead and wrap things up there. Hopefully this video helped you get started with automation in your own project, and let me know what kind of things you're using GitHub Actions for in the comments. Stay tuned for the giveaway video in a few days, thanks for watching, and and I will see you in the next one.
The speakers discuss automation and GitHub Workflows in a software project, highlighting their benefits for productivity and automation of manual or repetitive tasks. They also discuss the process of creating a new branch, deploying code locally, using a third party host, and setting up a trigger for job automation. A guide for developers is provided for future projects, including open source projects available through NPM. A tool called GitHub argue allows for automatic build and push of code to Azure, and setting up a trigger for job automation is discussed.

        [INST]
        You are youtuber called Fireship you make engaging high-intensity and entertaining coding tutorials and tech news. 
        you covers a wide range of topics relevant to programmers, aiming to help them learn and improve their skills quickly.
        
        Given the title of the video : 5 Ways to DevOps-ify your App - Github Actions Tutorial 
        and a small summary : The speakers discuss automation and GitHub Workflows in a software project, highlighting their benefits for productivity and automation of manual or repetitive tasks. They also discuss the process of creating a new branch, deploying code locally, using a third party host, and setting up a trigger for job automation. A guide for developers is provided for future projects, including open source projects available through NPM. A tool called GitHub argue allows for automatic build and push of code to Azure, and setting up a trigger for job automation is discussed.
        [/INST]
        
        Generate the video : One of the best ways to increase productivity in a software project is to automate anything manual or repetitive, and you might be surprised at how easy automation is to implement when you use an awesome tool like GitHub Actions. In today's video, we'll look at 5 different techniques that can improve the quality of your code and make your life more productive through the magic of Dev boss. If you have no idea what terms like Continuous Integration and Delivery mean, you will by the end of this video. And if you choose to follow along with your own project, we will automate the hell out of it. If you're new here, like can subscribe, and grab the full write up from FireShip. Io. Before we get started, I'd like to take a second to say thank you, because the channel just surpassed 300,000 subscribers. To celebrate that, I have a big giveaway UI plan in the next 100 seconds of code video that everybody can participate in. Stay tuned for that in a couple days pending the apocalypse. We're all gonna die. Now to get started with today's video, the only thing you really need is a GitHub repository, and the service has a very generous free tier, so don't worry about paying for anything upfront. Now before we jump into these 5 different DevOps recipes, let's answer the question of what is GitHub Actions? Consider a repo one GitHub. There are all kinds of different events that can happen to that repo. Someone might start the repo, send a pull request, or you might merge code into the master branch. These are examples of events, and any event can trigger an automated workflow. A workflow can spin up 1 or more containers for you in the cloud, then you provide a set of steps or instructions for the container to do something useful for you. GitHub will log the progress of each step and make it very clear if something failed. Now the really cool thing about actions is that instead of writing your own steps from scratch, You can use ones implemented by the community. You can think of each step as a reusable chunk of code, which we call an action. On GitHub, you'll find hundreds of reusable actions that solve common problems, with each one being its own git repo that you can fork and customize as needed. But I think the best way to get started is to look at some real world examples. A good starting place is continuous integration, And if you have no idea what that term means, make sure to check out my 100 seconds of code video on that topic. The whole idea behind continuous integration or CI is to have developers submit their code to the main code base in small maintainable chunks, usually on a daily basis, and those changes should be automatically tested against the main code base. Let's take a quick tour of the code. Inside the package JSON, you can see I have a set of scripts here. We use Jest to run automated tests and then build to build the app with Webpack. The app itself is just a simple website that tells you what day of the week it is. Inside the source directory, we have app JS with a JavaScript function that implements that logic. And then we have app dot test dot j s to test that logic. Feel free to clone this repo if you want to use it as an example, or better yet, use your own project as a starting point because these principles apply to any GitHub repo. When you visit your code on GitHub, you'll notice this actions tab. This is where you can monitor your workflows. When a workflow is triggered, it will give you a log of everything that happened on the server. What we wanna do for continuous integration is have our test suite run anytime there's a pull request to the master branch. If the test suite fails or if the code fails to build, we should get a red check mark here, automatically telling us not to merge that pull request. But but if everything goes according to plan, we should get a green check mark. Now back in the source code, you can see I have a GitHub directory followed by workflows, and a file called integrate dot yaml. Anything in this workflow's directory will be picked up by GitHub and automatically set up as a workflow in the cloud. The YAML file is where we define the workflow. Flow. We'll give it a name of node continuous integration, then we need to tell it on which event or events to run. We do that with the on object, And in this case, we want to run it on pull request to the master branch. Now every workflow should have 1 or more jobs. You define them on this job's object, and then first give the job a name. We'll call this one test pull request. From there, we need to tell the job which VM to run on. I'll run this one on Ubuntu, but you also have the choice of Windows and macOS. Next, we need to give this job a set of steps or instructions that actually build and test our code. We'll first want to get our source code into the virtual machine. We can do that using an officially maintained action called checkout. That brings your source code into the current working directory, And that means you can run commands like you would from the command line if working on the project locally. But in our case, we also need to set up Node. Js in order to run those commands. So we use the node setup action and then specify the version. And from there, we're ready to start running our own commands. We first need to install all of our dependencies from npm, And we can do that using the c I command. That's equivalent to npm install, but it does a clean install for your c I server. From there, we'll run our test command to test our code. And then after that, we'll run our build command to make sure the build compiles properly. Now it's also worth noting that if you have a more complex test suite, like end to end tests with Cypress for example, There's very likely an existing action to set up the test runner for you automatically in the environment. And that's all it takes for the workflow configuration. To start using it, we just need to commit it to the master branch. I'll run git add, git commit, and then git push to push that to the remote repository. Now if you go to the actions tab on GitHub, you'll notice that it's still empty. That's because we haven't had an actual pull request event to trigger a workflow. So let's go ahead and give our workflow a spin by creating a pull request. I'll go ahead and create a new branch using git checkout with the b flag to automatically move into it. Inside that branch, I'll make some changes to the source code that caused the test to fail. I'll then commit those changes and then push this branch to the remote repo. When I go back to GitHub, I'll see the option to create a pull request, which I'll go ahead and do. And you'll notice that it indicates how we're running checks or continuous integration tests in the background. If we go to the actions tab, we can see logging for this process running in real time. In this case, the test on the pull request fail, which means we probably shouldn't integrate this code into the main code base. And as the developer who submitted this code, I can look at the logs and realize what I did wrong. In this case, since I have an open pull request, I can go back into my code and fix it and then push another commit to this branch. GitHub will automatically rerun the workflow because this is an open pull request, and this time around we get green check marks. So that takes care of our continuous integration. Now it's time to move on to the next phase, continuous deployment. At this point, we're confident we have a valid pull request, And when we merge that code into the master branch, we also want to deploy the app to our customers. So continuous integration is about merging new code into the code base, while continuous deployment is about pushing that code out to your customers. To demonstrate this, I'm going to integrate a third party host, Firebase. And I'd like to give a shout out to Mark Stammaryohan. He put together an awesome guide that will take you through each one of these steps, so make sure to check that out on FireShip IO. We can easily set up hosting locally by running firebase init hosting, then we can push our code to our Firebase hosting account using Firebase deploy. We can do all this locally because we're authenticated into our Firebase account on our local system. But how do we authenticate a remote CI server to do the same thing? What we'll need to do is share a secret token with GitHub. We can obtain that token from Firebase by running Firebase login c I. This will return us with a token string, which you can think of as an API key or username password combination. Make sure to keep this value secret. Go ahead and copy the value from the command line, and then head over to your GitHub repo, go to settings, then secrets, and add a new secret. We'll give it a name of Firebase token in all caps, and you'll wanna make sure to use that same name. Then we'll paste in the token and save it. GitHub will automatically encrypt this value for us, and then we can access it securely from our CI server. In other words, it gives us a way to securely authenticate with Firebase from a GitHub Actions workflow. Now let's go ahead and create another YAML file in the workflows directory. This one we'll call deploy. Instead of running this workflow on a pull request, we'll run it on a push to the master branch. So this workflow will run if we push code directly to the master branch, or if we merge a pull request into it. Now the job itself looks almost identical to the previous job. We check out the code, set up node, run our build command, but then we need to deploy it. And to do that, we're going to use a third party action called the Firebase action. This action takes care of all the steps required to set up the Firebase CLI on your server. It will run the Firebase command, and then we tell it to use the arguments of deploy only hosting. Then it's going to be looking for an environment variable of Firebase token. We can access our secret GitHub value by using dollar sign, double braces, followed by secrets dot firebase token. And that's basically all there is to it. We can start using this continuous deployment workflow by pushing it to the master branch. Now if we go back to GitHub and merge that pull request from the previous example, You can see from the login that it automatically builds and deploys our code to Firebase, and the changes should be automatically reflected on the website itself. And now that we have a basic CICD pipeline, I wanna look at some other cool things you can do with GitHub Actions that you might not realize. Personally, I maintain a few open source projects that are available as libraries through NPM. One of those projects is Svelte Fire. And anytime there's a major code change on the master branch, We cut a new release so developers can use that code in their projects. And every time that happens, I also need to go to the command line, log in to npm, and push that code to the npm registry. It's kind of annoying and easy to forget, so let's just automate it with GitHub Actions. In this workflow, you'll notice I'm using the release event. That's because not every code change on the master branch requires a new release. For example, if you just fix a typo in the Readme, it doesn't require a whole new release to be pushed out to NPM. PM. In this recipe, you'll notice we have 2 jobs, 1 for build and one to publish to NPM. And we might want an additional job to publish to the GitHub package registry. By default, all the jobs will run concurrently in parallel. But that's not actually what we want here because we want to first build our code before releasing it to the package managers. We can use the needs keyword to tell GitHub actions to run this job after the previous job is finished. This can be a really useful technique because in our case here, it allows us to build the code once, and then push it out to 2 different registries without having to rebuild the code. So that's really useful if you're a library maintainer, but most companies use a lot of other communication tools beyond GitHub, like Slack, Discord, Jira, Trello, and so on. And in most cases, these tools maintain GitHub apps for you to integrate with their tools directly in GitHub. When you go to the GitHub marketplace, you'll notice that it's separated by apps and actions. Actions are reusable pieces of code you use in your own workflow, while apps are fully pre built solutions that don't require you to deploy any code whatsoever. Because we use Slack for Fireship IO, I'm going to use that as an example. Let's imagine that I wanted to receive a Slack notification every time a new GitHub issue is posted. There are a variety of community maintained actions that allow me to do this easily in a workflow. In this workflow, you can see I set up a trigger for GitHub issues, then use a Slack action along with some configuration variables to have it post messages directly in my Slack channel every time there's a new issue on GitHub. That's cool and all, but you can also solve this problem using a GitHub app, and it can be installed on your account by simply clicking a few buttons. The nice thing about a GitHub app is that it can be used across multiple repos simultaneously. So when you're automating with GitHub Actions, it's a good idea to ask yourself if you want a fully installed app or if you want to build your own workflow with Actions. I may do a whole separate video on apps because there's a lot of cool things you can do, like automatically analyze code quality, automatically update your dependencies, automatically optimize all your images, and automatically do a whole bunch of other cool stuff. But now let's shift gears into the final recipe, which is a GitHub action that runs on a specific schedule. This one happens to be a special treat for Firebase users because it solves a common problem. How do I export my Firestore data on a regular basis? Currently, the database doesn't provide automatic backups, so you need to manually export your data in order to reimport it in case of a disaster. In this recipe, we use the on schedule event and pass it a cron schedule. If you don't understand how this cron syntax works, don't worry. Not many people do, but there's an awesome app called the Chrontab Guru that can automatically generate schedules for you. The schedule in this example runs every night at midnight. And then in the action itself, we're using an action maintained by Google Cloud Platform. This action sets up the gcloud CLI in the environment, and then we can use it to run a couple commands to export our Firestore data into a storage bucket. And that process is now fully automated, so we should hopefully never have to worry about it again. And check the links in the description for a full write up on how to set up the service account and everything else involved with gcloud. I'm gonna go ahead and wrap things up there. Hopefully this video helped you get started with automation in your own project, and let me know what kind of things you're using GitHub Actions for in the comments. Stay tuned for the giveaway video in a few days, thanks for watching, and and I will see you in the next one.
        