[MUSIC PLAYING]
SPEAKER: Hi, everyone, and welcome back to the series
"How Firebase Projects Work."
In this episode, I'm going to cover
environments and emulators.
In the first episode of the series,
we covered how to set up your Firebase project
and your Firebase apps, and the best practice recommended
by the Firebase team.
Now we are going to deep dive into one of the scenarios where
it can be useful to use multiple Firebase projects, which
is to support different environments.
For production apps, you need to set up a clear development
workflow or deployment pipeline, which
usually involves setting up and managing multiple environments.
An environment consists of all the hardware and software
that are required to run an instance of an application
or system of applications.
It's often necessary to create different environments
for different purposes.
For example, for security reasons,
you will probably want to create a different user base
and database for each environment.
You might also want to create different environments
so as not to exceed the API tracking
limits for some services or not to exceed the different quotas
for each service.
And if you're using Google Analytics,
another good reason to have different environments
is to make sure that your Google Analytics
data is pristine and only accounts for events occurring
in your production environment and not
events generated by any test you've
performed in your testing environment.
So let's take a look at some types of environments.
First, let's talk about the development environment.
This is where developers will write the code
to create new features, improve existing code,
and fix any existing bugs.
It should be a safe, isolated place
to test changes as they're being built.
Because of that, the data in the dev environment
can be almost anything.
Over time, you will probably accumulate
things like artifacts from past bugs you have fixed,
images that were used for testing
or that needed to be resized, a username with emojis in it,
and product logs filled with fake data
to force pagination bugs you once investigated.
It can be handy for each developer working on an app
to have a separate dev environment in order to avoid
overwriting each other's work.
And to iterate faster during development,
it is very useful for each one of these developers
to have a local instance of their dev environment.
We will talk about the tools that Firebase
offers to speed up development in different environments
later in this video.
Once you have finished developing
a version of your application, you definitely
want to test it in a testing environment.
This environment should replicate as closely
as possible the same execution environment
that will be exposed to users in production
so that tests accurately reflect the real end user experience.
Like with all non-prod environments,
it's very important to keep the data and user accounts
for your test environment separated from what's
used in your production app.
And if you have QA engineers, they
may need one environment that they all use,
or they may need individual environments
to test a new release candidate.
Once you're confident in your new version,
you will probably want to share it more broadly for review
before releasing it to your users--
maybe with your product manager, for example.
But you still need to do this final review
in a controlled environment-- your staging environment.
This environment should simulate production infrastructure
as much as possible, and its data
should be realistic, but still be fake.
And finally, your new version is ready to go
to the final environment-- production.
This is the environment where your app
can be used by the end user.
And this is the environment where
you need to be very careful when you're touching data or making
other changes because losing or altering your production data
will directly affect your users.
And these are the most common environments--
dev, test, staging, and prod.
So if your software development workflow
includes different environments as well,
you can configure different Firebase projects
for each one of them.
After all, we just covered how important
it is to isolate the data used in each stage of the deployment
pipeline.
Now let's see how you can have different environments
when using Firebase.
The first thing that you need to do
is set up different Firebase projects
for your different environments.
You can do this in the Firebase Console
or in a variety of programmatic ways.
If you choose to do it using the Firebase Console,
you need to create a new Firebase
project for each environment, as you
can see here on this dashboard.
The Firebase team recommends tagging the Firebase project
associated with your production environment
as a production environment type in the Firebase Console.
This tag will help remind you and your teammates
that any changes in this specific Firebase project
could affect your associated production apps and their data.
To change the environment type of your Firebase project,
go to your project settings, open the General tab,
then click Edit to change the environment
type under the environment configuration.
The next thing you need to do in each of your Firebase projects
is register the release status variants of your app
with the appropriate Firebase project.
This means that you need to register all your debug
builds--
iOS, Android, and web-- with one of your non-production
projects and register all your release builds-- again,
iOS, Android, and web-- which are production project.
Once you have created the different Firebase projects
and registered your apps, you'll need
to configure your code base to know
when and how to access these different Firebase projects.
And there are different ways you can configure your code
base to do this, depending on whether it's an Android, iOS,
or web app.
You can learn how to do it for each platform
in the official documentation.
To give an example of when your codebase would
need to access different Firebase projects
is when it's interacting with a database.
If you're testing the new version of your app,
your code needs to access the database of your test Firebase
project.
But once the version has been released,
your code needs to switch over to access
the database of your well-protected prod Firebase
project.
Oh, and speaking of well-protected,
don't forget to make sure that you have Firebase security
rules set up in all the environments, even
the pre-production ones.
In general, security rules should be the same
across all the environments.
Now, you may be wondering, do I really
need to create different Firebase
projects for every new environment,
or is there any way I could do it locally,
especially when I'm quickly iterating during development?
In fact, there is-- the Firebase Local Emulator Suite.
The Firebase Local Emulator Suite
is a set of tools for developers who
want to use Firebase in their app and test locally.
It contains individual product emulators
built to mimic the behavior of Firebase services.
Each one of them responds to SDK and REST API calls just
like real Firebase services, so you can connect your app
directly to these emulators to run
your test without deploying real resources
or touching real data.
The Local Emulator Suite is a good fit for our development
and testing environments, especially if you're
iterating on your back end database,
Cloud storage, authentication, et cetera.
You can also emulate admin SDK functionality,
and you can even try out a Firebase extension
without actually deploying it to your project.
In addition to local development,
the Emulator Suite can also plug into your [INAUDIBLE] pipelines
used for testing end staging.
One more thing-- we are regularly
adding emulator support for more Firebase products and features,
so check out the Local Emulator Suite
docs for the most up-to-date listing.
Beyond all the services available in our Emulator
Suite, there are also other tools
that help you in the prototyping and testing
phases, such as Cloud function testing tools and security
rules testing tools.
The link to these resources is available in the description.
One piece of the Local Emulator Suite
that makes rapid iteration easier
is the Firebase Emulator UI.
This is a visual tool that allows you to use the product's
emulators in a similar way that you could use the Firebase
console during development, like seeing if a new database
structure or access scheme is behaving as expected.
The official documentation teaches
how to configure both the Emulator Suite and the emulator
UI locally.
There's also this codelab that has
the step by step of how to start with local development
with the Firebase Emulator Suite,
and then an amazing video called "The Local Firebase Emulator
UI in 15 Minutes" that answers many questions you
might have regarding the Firebase Emulator UI.
All links covered in this video are
available below in the video description.
And that's all for today.
Next in the series, we are going to talk
about the different billing plans.
Thank you all for staying with me until the end of the video,
and see you soon.
[MUSIC PLAYING]