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 five
different techniques that can improve
the quality of your code and make your
life more productive through the magic
of DevOps 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
and subscribe and grab the full write-up
from fire ship IO before we get started
I'd like to take a second to say thank
you because the channel just surpassed
three hundred thousand subscribers to
celebrate that I have a big giveaway
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 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 five different DevOps
recipes let's answer the question of
what is github actions consider a repo
on 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 one 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 codebase and small
maintainable chunks usually on a daily
basis and those changes should be
automatically tested against the main
codebase 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 just
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 KS with a
JavaScript function that implements that
logic and then we have apt SJS 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 want to
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 checkmark here
automatically telling us not to merge
that pull request 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 gamal anything in this
workflows directory will be picked up by
github and automatically set up as a
workflow in the cloud the gamal file is
where we define the workflow 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 one or
more jobs you define them on this jobs
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 Mac OS next we need to
give this job a set of steps or
instructions that actually build and
test our code well first want to get our
source code into the virtual machine we
can do that using an officially
maintained action called check out 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 nodejs 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 CI command
that's equivalent to NPM install but it
does a clean install for your CI 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
bill
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 get 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
be flag to automatically move into it
inside that branch
I'll make some changes to the source
code that cause 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 a
continuous integration test 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
tests 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 checkmarks 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 stammer Johan he put
together an awesome guide that will take
you through each one of these steps so
make sure to check that out on fire ship
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 fire
by running fire-based login.c I this
will return us with a token string which
you can think of as an API key or user
name/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 and secrets and add a new
secret we'll give it a name of firebase
token in all caps and you'll want to
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 gamal file in the
workflows directory this one we'll call
it 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 setup
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 setup
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 and 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 CI CD pipeline I
want to 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 spelt 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
login 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 and this workflow
you'll notice I'm using the release
event that's because not every code
change on the master branch work
is 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 in this recipe you'll notice
we have two jobs one 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
two 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 disk or 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 fire
ship 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 in 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 if the database doesn't
provide automatic backups so you need to
man
export your data in order to reimagine
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 crontab 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 a Google cloud platform this action
sets up the G cloud 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 G cloud
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 are using github actions for in
the comments stay tuned for the giveaway
video in a few days thanks for watching
and I will see you in the next one
[Music]
