[MUSIC PLAYING]
JEFF HULEATT: Bringing a map from idea to production
is a big task.
And it takes more than just code.
It involves a whole team.
As app developers that use Firebase,
we probably spend a lot of time thinking of the technology
we'll use and the engineering decisions we'll need to make.
But working on a team brings its own advantages and challenges.
Without these team members, we wouldn't get far.
But collaboration can be tricky too.
And poor communication and teamwork
can ruin even a great idea.
In this case, our idea is to build an online multiplayer
tic-tac-toe game.
Nobody likes constant status check-ins,
having frustrated teammates that feel out of the loop,
or wasting time on dead-end projects.
We just want to build something great.
So how do we work better with our team
while still spending most of our time on code?
My name is Jeff, and I'm going to show you
how a few simple tools can make the product development
lifecycle from idea all the way to launch easier for our team.
First, let's get to know our example team.
There are likely many people involved in a real project,
like other developers, testers, support.
But we'll just focus on a couple of representative roles.
Besides the developer, meet our other two team members.
The product manager, Patty, is the one
that coordinates our team and is responsible for turning
our idea into reality.
She may have to answer questions from the stakeholders
higher up in our business, likes to check in
to make sure we're on track, controls costs, and ultimately
gives the final approval before launch.
Doug is responsible for the visual design and user
experience of the product.
More than just checking in, Doug works
alongside us developers as we implement his designs,
pointing out issues, and sometimes adjusting designs
to meet development constraints.
And that's our team.
We wrote this proposal for a new web game.
We have approval to explore the idea.
We even have a shiny new Firebase project set up
to use during development.
But where do we actually start?
Well, it often starts with a demo, something
to make sure that the idea is worth pursuing.
And in this case, the product manager, Patty,
has reached out to me and asked for exactly that.
So a demo.
I guess I have to build one.
What do I do here?
It might help to think of what each team member would
like to see in a demo.
At this stage of the project, we need
to build the bare minimum to prove that our project is worth
investing our time in.
That's it.
Patty wants to know that the project is possible.
And a demo will also give her an idea of how long it
will take to launch.
Doug probably needs to see something just real
enough to know if his initial design ideas will work.
And I want to prioritize building as quickly as possible
and get an idea of the architecture
so that I'm certain it can scale to lots of users
if we do decide to pursue the project.
The Firebase Emulator Suite is a great way
to try things quickly.
It lets me run a bunch of Firebase services
locally on my machine, letting me iterate
and break things without worrying about it affecting
a real Firebase project.
The Emulator Suite doesn't support every Firebase product.
But for this demo, I think I only
need real-time database and hosting, which are supported.
If I needed to use a Firebase product that wasn't supported
by the emulators, I would need to use my development
in Firebase project for testing.
I'll configure the emulators with the Firebase CLI
and add code that tells the Firebase SDKs in my app
to talk to the emulators instead of to a real Firebase project.
Now I can quickly iterate on the prototype
with all the Firebase services running locally on my machine.
I can even use the convenient Emulator
UI to manually add data and users for even easier testing.
Once the demo is complete, I'll need to share it
with my team, of course.
Since it's only running locally, I
don't have a URL to share with them.
But that's OK.
At this stage, this simple demo is
enough to help us make the decision to move forward
with the project.
How'd it go?
After the demo, I got this message from our PM.
Looks like the quick hacky demo was a success
and showed the team that this project is worth pursuing.
So now I'm going to check my code into GitHub.
Things are getting real.
And now, I'll start working with a designer.
I'll have to share updates and get their approval
as I make changes.
My workflow for the initial prototype, developing locally
with the emulators, scheduling a meeting with Doug
to show him every little update probably
isn't practical anymore.
We'd spend way too much time in meetings
and not nearly enough time improving the app.
Plus, now my code is in GitHub, and I'd
like to work on each feature as a pull request
so that things stay nice and organized
and I can get feedback from Doug on each piece.
So let's think about what to do instead.
I'd like to find a way for our designer, Doug,
to know my progress at all times and leave feedback
when he's available to do so.
It would be great if Patty could drop
in on our conversations sometimes
to make sure things are going smoothly.
Ideally, I'd like this all to be automated
so I can spend more time coding and less time
giving status updates.
Since the code is in GitHub, let's use GitHub Actions.
Using the deploy to Firebase hosting GitHub action,
I can automatically create a unique temporary preview
URL for each pull request in my repository.
This will let Doug give feedback right in GitHub
where I'm working.
And any pull requests created by other developers on the team
will also automatically get a preview URL.
Plus, we can share these preview URLs with our product manager
so she can easily view and interact
with the work in progress site.
Let's set it up.
I just need to run the Firebase init hosting GitHub command
from the Firebase CLI.
That will set up a GitHub workflow
that can deploy to my development Firebase project.
When I create a PR at the first milestone,
we can see that the action comments a preview URL
right into the PR.
Now Doug can easily visit any pull request in GitHub,
click the link, and see a live working version of the app
based on the code in that PR.
Doug, or any other team member for that matter,
doesn't need to build a source code
or set up a meeting with me to see the latest app.
Less meetings.
I'll let Doug know I'm ready for his comments
by sending him a link to my first pull request.
Then we'll work together on each pull request
until the app looks as good as his original designs.
OK, I've been hard at work implementing.
And I finally got the app in a place that meets
Doug's exacting requirements.
Great.
We've come a long way from the initial emulator prototype.
Let's get ready to share this with the world.
There are some things I'll need to do to the app itself
before going to production, like instrumenting
with Google Analytics.
I'll also need to make it secure.
There's actually a learning pathway
in another talk at I/O this year all
about how to set up authentication, security rules,
and app check to make sure your app is as secure as possible.
But in terms of working with my team,
is there anything I can do now that will make it easier
to collaborate and maintain the app over time
even as our team grows?
Patty wants to know how much our game will cost to operate
once it is in production.
Doug wants to make sure new features are
as easy to collaborate on as before, because he really
liked that workflow.
And I want to make sure that the project is easy to maintain
and that any bugs are caught early--
hopefully before they reach production.
First, I'll create a test project.
This is a separate Firebase project
that has all its services set up just like the Firebase project
that will actually host the production app
but doesn't serve any production traffic
and only contains test data.
Then, I'll configure the deploy to Firebase hosting GitHub
action that I set up before to use this test project instead
of the development project.
Since we know the test project won't contain any real user
data, we can confidently visit and test any preview URL
without worrying about affecting real data.
I'd also like to set up automated testing,
also known as continuous integration, or CI.
For that, I'll actually use the Emulator Suite again.
The emulator's exec command will start up at the emulators,
run a script where my app code can communicate
with the emulators as if they were talking to a real Firebase
app, and then shut the emulators down.
I can do this in a GitHub workflow
to run a full test suite against the emulators including
security rules on every pull request,
making us more confident that we haven't broken anything
before merging and shipping to production.
I'll let Patty know that things are all set.
Oops.
Thanks for the reminder, Patty.
We may have made sure we won't break our app.
But what do we do about costs?
The Firebase Docs have a pricing calculator.
This lets me plug in rough usage numbers
and gives an idea of our total monthly costs.
Thankfully, Patty has done market research
to figure out the number of monthly users we're expecting.
I can combine that number with my knowledge of the app's
architecture to get a rough estimate of usage
and then plug that into the pricing calculator
to estimate how much the app will cost us every month.
Once I have that information and confirm it with Patty,
I'll make sure to set up budget alerts for the project.
That way, our team will get notified
if we're spending more than we think and can explore
why that might be happening.
Note that these don't actually turn off
billing if we had our budget, because we
don't want to have to be shut off right as it's going viral.
Instead, we'll get email alerts as we pass certain thresholds,
like 25%, 50%, or more of our budget,
so that we are aware and can troubleshoot if needed.
I'll let Patty know that we have billing alerts set up
based on our estimates.
Did I forget anything else?
No.
Excellent.
Looks like we're good to go.
Since I've been working in a Firebase project meant
for development up to now, I'll create a production Firebase
project that has all the same configuration
as our development project but is locked down
to only the people that need to access it, since from here
forward it will contain real user data.
Then we can launch.
And launch we will.
We did it.
Our app is launched.
Let's recap.
Before fully committing to the project,
I built a quick demo with the Firebase Emulator Suite
and showed the app to my team in a meeting.
That was enough to get approval to continue with the project.
But then I didn't want so many meetings anymore.
So Doug and I collaborated on improving the app in GitHub.
And we used the deploy to Firebase GitHub
action to deploy previews to the development Firebase project.
To get Petty's approval to launch the app,
I use the Emulator Suite in a GitHub action
to set up a CI testing pipeline.
And I also made sure we had a test project with test data
so that we can safely manually debug the app
and continue to deploy previews on new pull requests.
And Patty and I used the pricing calculator in the Firebase Docs
to set budget alerts.
Then, we launched in a production Firebase project.
Where do we go from here?
Well, we can use this process over, and over, and over again
as we have new ideas for features and apps to come.
As app developers, we're just one piece of a bigger team.
By using the right tools with Firebase,
I was able to effectively collaborate
with my team on each step of the development journey
from prototyping, to building the real product,
all the way to bringing it to production.
No frustrations here.
Just a happy team that doesn't spend too much time
in meetings that was able to launch with confidence.
Thanks for joining.
I hope some of these tips were helpful to you
so that you can have the same experience our team did.
Thank you.
[MUSIC PLAYING]