♪ [music] ♪
Hi, I'm Michael, an engineer on the Firebase team.
Getting a public web app set up with Firebase hosting
is super simple, but we hear a lot of questions
about how to bring a site to production.
So today, we're going to show you a few steps for getting ready
for the big launch and for managing your app
once it's out in the wild.
My team has been building a site called Friendly Eats.
It's a restaurant review app
and we're finally about ready to launch it.
But before we do, I'm going to take a few steps to make sure
that my site is ready for real users.
So what do we need to do?
Something I've already done is create a second dev Firebase project
for my app.
This way, my team can test out new features
without worrying about breaking our production app.
I've also already upgraded my production project
to the pay-as-you-go Blaze plan.
That way, I know my site won't get disabled
if I exceed the free quota.
When I upgraded, I set a budget alert so there won't be any surprises
on my monthly bill.
Now, we're going to change some of our production project settings
to get ready for launch.
We'll make it easier to see what's happening with Cloud Logging,
and better secure our project by tightening permissions.
After that, we're going to automate testing
in deployment of our site to make development fast and predictable.
Let's get started.
[whooshing sound]
As you can see, I have two Firebase projects here--
a production and a development project.
I'm going to go into my production project
and go to the
From here, I'm going to go to
and scroll down and see
So I want to enable Cloud Logging so that I can see request logs
for everything that my users do on my site.
So I'll click here, go ahead and
turn it on,
and that's all I have to do.
So now, every time a request hits my production website,
I will see a request in Cloud Logging,
which we'll come back to later.
Now, I also want to review all of the users
that have access to my app.
So I'm going to go to settings,
and here we have three members in my project.
Myself, and Ke, and my teammate, Cam.
Now, Cam is currently listed as an editor,
but Cam really only works on the backend.
So I'm going to click on Cam, change their role,
and say that they are a
but they don't need access to the
and they don't need to be able to modify permissions
or anything like that.
So I'll click
Now this is just something that is a good practice to do.
Before you go live to production,
you should review all of the members in your project,
and make sure that they have appropriate access.
Now, I'm going to jump over to the Google Cloud Console
to restrict the permissions of the browser API key
that Firebase uses to call various APIs.
I'm going to navigate to
and then
From there, I see that there's a browser key
that was automatically created by Firebase.
So I'm going to click into that,
and I'm going to add two types of restrictions.
First, I'm going to restrict what types of websites use my API key,
then I'm going to restrict which APIs my key can call.
For the websites, I'm going to add my website,
which is
my
and also the URL for my QA preview channel
which I'll be setting up in a little bit.
For API restrictions, I'm going to restrict the key
to only a set of Firebase APIs.
So I want to select the
Management
and I also want to select the
which is what Firebase oft uses.
So now that I've restricted both the URLs and the APIs
for this API key, I can save that,
and now my API key is ready for production.
We're getting close to launch day, and I'm feeling pretty confident
about my app's security and stability.
I've completed most of my production checklist,
but one big step remains.
I want to automate deployment and testing of my app
to make a reliable workflow my whole team can use
to bring features from idea to production.
To do this, we'll use Firebase Hosting preview channels.
Channels let me deploy work in progress versions of my site
to a temporary URL that I can share with my team.
I can deploy to channels manually using the Firebase CLI,
but we've also added some help to make it easy to integrate channels
directly with GitHub.
Let's give it a try.
I'm going to start by adding my new
to my
The
You can see that right now, I only have a default project,
which is
I'm going to run
and link my
This brings up a list of my Firebase projects,
and I'll go down and select my
Also call it
This writes configuration to a
in my project directory.
You can see I have both
I'm going to quickly rename
so that I always know which environment I'm dealing with.
Once I've done this, I can easily swap between projects.
So I can say, "firebase use dev" to switch to my
or I can say, "firebase use prod" to switch back to my
I can also use a flag to do this on an individual command.
So if I want to deploy to
I can say, "firebase deploy --only hosting --project dev,"
and now it will deploy to my
This makes it easy to use multiple projects with the Firebase CLI.
Now that the CLI knows how to work with all of my environments,
I need to make sure that my app does too.
I've created environment-specific initialization files
for my local, development, and production environments.
In this case, I'm just trying to make it easier to see
which environment I'm in,
but I could do any kind of environment-specific initialization here.
To integrate these with my deploy process,
I'm going to add a
This will run a list of commands before every deploy.
In this case, installing dependencies and running a
A useful feature of the
is that it provides a
for the current project to all scripts that it runs.
Switching over to my
to copy environment-specific initialization
based on the
And I'll fall back to
I'll then run the new
that happens every time I run my app.
Let's take a look at this in practice.
I'm starting up my local
and we'll also deploy first to
using a
Once that's done, switching over to my browser,
I can see that on
my
on my
and in my
Being able to competently use any of my environments
without manually tinkering with settings
can really speed up development.
To improve the workflow for my whole team,
I'm going to further automate deploys using GitHub actions.
The Firebase CLI will help me get this started step-by-step
with the
After authenticating with GitHub, the command asks for a repo,
automatically detecting the origin remote that I'm using.
Next, it fetches a service account key for my Firebase project
and stores it as a secret in my GitHub repository.
Because I configured a
I don't need to add an extra build step.
The default flow will automatically deploy preview channels
for pull requests.
But I'll also have it deploy to the live version of my
when I merge into my
Now, set up is complete, and I have two new workflows
in my
One will run whenever a new PR is opened or updated in my repo,
and will automatically deploy to a preview channel on my
The other will run when a PR is merged
and will deploy to the
To complete my workflow,
I'm going to copy the deploy on merge action
into another action, this time to target my production environment.
When new code is merged into my main branch,
this action will deploy to a
for final verification before release.
And now we have the complete picture.
Let's jump ahead to see how this works in action.
I have open the
but I've been working on a redesign in preparation for launch
in my
There we go.
This is definitely going to stand out from the crowd
when we launch.
Perfect. I think we're all ready to send this out.
Switching back to my Editor, I'm going to commit my changes
in a
To use the GitHub action I already set up,
I'll need to create a pull request.
Here's the branch, so I'll go ahead and create one.
Creating a pull request will deploy my site to a preview channel
without affecting any existing deploys.
I'll make my pull request against the
Now, my pull request is open,
and I can see a
has started running.
If I want to, I can click through to watch the deploy progress,
but it's all happening automatically.
Under the hood, the GitHub action is just running
the same Firebase deploy commands I could run locally.
Once the action finishes running,
it will automatically post a comment with a preview URL
back to the pull request.
[whooshing sound]
From here, my work on the new feature is done.
My teammate, Ke, is going to take a look and review it
before it goes to production.
Over to you, Ke.
[whooshing sound]
Michael shared the URL of his new preview channel with me.
Let's pull up this URL to see what he updated, and test it out.
So I'm on the preview channel now.
I see Michael's update and it looks good.
Note this preview channel is fully functional.
If I submit a review here, then...
this review will get added to the database in my staging project.
Let's look for that review in the Firebase console.
Okay, there it is.
Since the updates that Michael made look good,
I'm ready to merge his PR to our staging branch.
Our staging branch is connected to our Firebase staging project.
When I merge Michael's PR,
it automatically deploys to our staging site.
So let's merge.
And there it is.
The updates are now on the staging site.
Now, Firebase hosting gives you the tools you need
to set up your own workflow.
It's flexible depending on what works for you and your team.
We showed you how we set it up, but remember,
you can customize it for your own workflow.
To recap our workflow, Michael and I created a website,
Friendly Eats.
We have a staging environment
with a staging project and staging hosting site.
And we have a production environment
with a production project and production site.
When Michael first deployed his changes,
he was working in the staging project.
His new PR triggered a deploy to a preview channel
on the staging site.
If he updates that PR, those updates are deployed
to that same preview channel.
That way, the URL stays consistent.
After I looked at Michael's PR, I merged it to our staging branch.
We set up our workflow
so that when a PR is merged to the staging branch,
it's automatically deployed to the staging site.
At this point, things are generally looking pretty good,
and I'm ready to deploy these changes to our production site.
But hold on-- my production site is a different environment.
It's in a different Firebase project,
and it has a different backend than my staging project.
Even though my staging project mimics my production project,
you never know what might be a little bit different.
So we've set up our workflow to include a last sanity check.
When I merge my staging branch into my main production branch,
this kicks off an automatic deploy
to a preview channel for my production site.
This preview channel, which we've named
allows me to test out the updates with my live production backend.
It's a way for the team to see the newest updates
that are ready to go out to end users.
Once I feel confident that what I see on the
is exactly what I want on my
which is my user-facing site, I can use the
to make sure it's copied over exactly.
To do this, I'll run the command
I'm cloning from my production site's
to my production site's
The
and what my custom domains are linked to.
Cloning... and done.
Both the
Remember, this is just one way to set up your workflow.
We provide you with flexible tools,
such as our preview channels feature and our GitHub action
so that you can set up a workflow that works for you.
I also have Cloud Logging as a tool.
When Michael set up the Cloud Logging integration earlier,
he set up alerts.
But I can check my logs at any time, though,
by visiting my usage for hosting here.
Then I can visit the Cloud Logging console
to filter and search for logs.
If my newest update had any issues, I would see it pop up here.
For example, I can filter by 404s.
[whooshing sound]
We just went over a bunch of features and tools
for shipping production web apps with Firebase.
Let's recap.
Michael and I went through steps
to get ready for launching our Friendly Eats site,
including setting up different project environments,
setting up rules, getting on the Blaze Plan,
and adding Cloud Logging.
We also went over setting up a GitHub workflow
and using preview channels to share updates within our team.
Let us know what you think and share how you're using Firebase.
Thanks for joining us, and we look forward to seeing
all of your Firebase hosting apps in production soon.
Bye!
♪ [music] ♪