Every project tends to start small and simple and grow over time. This is particularly true here at Andromeda, where we specialize in building software products. Regardless of if we're building products for our clients or our own audience, these products tend to start small, with just a few features in an MVP. However, as we dream up new features, user requests come in, and as clients start to recognize their vision, things get more complicated.
This can have a direct impact on the DevOps of your project, including the deploy phase. This even affects simple platforms such as Google Firebase. We've recently gone through a few growing pains related to our Firebase deploys and I wanted to take the opportunity to share a few lessons we've learned.
Most of this article will assume that you're using the Firebase CLI (command-line interface) to perform your DevOps work on your projects. If you're using NPM this can be installed using:
npm install -g firebase-tools
While the Firebase CLI has it's own options, there are a number of options specific to deploy. Need the full list? Try this:
firebase deploy --help
Want to deploy just a single part of your project? Use
--only to make this happen. Examples:
firebase deploy --only hosting firebase deploy --only functions firebase deploy --only storage
You can also deploy individual cloud functions by name:
firebase deploy --only functions:countItems firebase deploy --only functions:countItems,functions:calcRevenue
One common thing you'll want to do is deploy functions one by one, but deploy the rest of your project all at once. Rather than chaining multiple instructions together with the
--only flag you can do just a single command:
firebase deploy --except functions
Firebase Hosting has the fantastic ability to roll back to previous versions, delete old versions, and explore your deploy history. But this isn't terribly useful if you don't know how each of these releases relate to your product version number. You can solve this problem using the message option:
firebase deploy --message "2.12.0-beta.1"
This would cause the version number to be displayed as a message on the history list.
Of course, you can use this message for anything you want but this is what my team has found the most useful. If you manage product versions inside of package.json you can even automate this:
firebase deploy --only hosting --message `node -p "require('./package.json').version"`
You might expect a deploy failure to cause the entire deploy to fail, or that everything would succeed except the specific item that errored. The reality is a bit more complicated.
Recently I had a single function fail in my deploy. Every other function deployed successfully, but hosting did not deploy (despite showing "file upload complete" in the output.
I recently started receiving the following error when running deploys using version 11.2 of the CLI tools:
Error: Cloud Runtime Config is currently experiencing issues
I was able to work around this issue by downgrading to version 11.1 of the tools, which can be done like this:
npm i -g firstname.lastname@example.org
In general I recommend running on the latest version of the tools, but sometimes regressions do happen. I would recommend downgrading only if you encounter the "Cloud Runtime Config" error.
This is a bit of a tangent, but the way you organize your Cloud Functions will have a direct impact on how you deploy your project. There are a few different options available.
- Keep all of your functions in one file. This really only works if you have 1-2 simple functions.
- Move your functions into multiple files, importing them into the main index.ts file. This makes your code much more readable and will get you pretty far.
- Combine your functions into groups. This is similar to the above option, but given a specific name for the group allowing you to use the group name on the command line in place of individual function names.
- Separate functions into multiple packages or repositories.
Firebase has proven to be an excellent platform for our team and our clients and has scaled with us well so far. As your software grows larger and more complex you'll need to find better ways to organize the code. And as always, if you need support on your own Firebase projects our team is here to help!