Deploying apps from circleci to Firebase hosting

The command line page of the Firebase documentation doesn’t list all the commands available to you from the firebase-tools npm package. To see them all, install the tools with npm install -g firebase-tools and execute the command firebase in your terminal.

Usage: firebase [options] [command]


  Commands:

    data:get [options]               fetch and print JSON data at the specified path
    data:push [options]  [infile]    add a new JSON object to a list of data in your Firebase
    data:set [options]  [infile]     store JSON data at the specified path via STDIN, arg, or file
    data:remove [options]            remove data from your Firebase at the specified path
    data:update [options]  [infile]  update some of the keys for the defined path in your Firebase
    deploy [options]                       deploy hosting assets and rules for the current app
    deploy:hosting [options]               deploy hosting assets for the current app
    deploy:rules [options]                 deploy security rules for the current app
    disable:hosting [options]              stop serving web traffic to your Firebase Hosting site
    help [command]                         display help information
    init [options]                         set up a Firebase app in the current directory
    list                                   list the Firebases to which you have access
    login                                  log the CLI into Firebase
    login:ci                               generate an access token for use in non-interactive environments
    logout                                 log the CLI out of Firebase
    open [options] [panel]                 open Firebase Hosting URL in browser or jump to a dashboard panel
    prefs:token                            print the currently logged in user's access token
    serve [options]                        start a local server for your static assets

  Options:

    -h, --help         output usage information
    -V, --version      output the version number
    -j, --json         output JSON instead of text, also triggers non-interactive mode
    --token     supply an auth token for this command
    --non-interactive  error out of the command instead of waiting for prompts
    --interactive      force interactive shell treatment even when not detected
    --debug            print verbose debug output and keep a debug log file

The interesting command here is:

    login:ci                               generate an access token for use in non-interactive environments

Run firebase login:ci and follow the instructions to receive an access token like awelkfjw8efwpafh8phaua9 that you can use within circleci to deploy your app.

Inside circleci

Save the access token in circleci’s project settings as an environment variable with a name like FIREBASE_DEPLOY_TOKEN. Then configure circle.yml to use the environment variable inside the deploy step like this:

deployment:
  master:
    branch: master
    commands:
      - firebase deploy --token "$FIREBASE_DEPLOY_TOKEN" --non-interactive

When a build on the master branch succeeds, circleci will use that command to log into Firebase hosting on your behalf (via the access token) and upload the files configured in your firebase.json file.

Links

using Compass during `grunt build` on Heroku with Strider CD

Long story short:

Environment plugin setup

First, I have to set the Gem install directory to path that can actually be written to by programs executed by Strider. I set the GEM_HOME environment variable to /tmp/gems using Strider’s environment plugin.

gem-heroku-strider-env

Custom Scripts plugin setup

Next, here’s the code to install and use compass used in the required phases of the build

Environment phase:

gem install compass

Prepare phase:

# add compass to the path
export PATH=$PATH:/tmp/gems/bin

optional lines for debugging:

# print the version number
compass -v
 
# show the compass binary's path 
which compass

gem-heroku-strider-scripts

Note that export PATH=$PATH:/tmp/gems/bin is above grunt build. Reverse the order and you’ll notice the grunt task can’t find compass on your machine since it isn’t added to the PATH variable util after the build fails.

Full Stack Toronto meetup July 2, 2014

Nick and Xiyang will discuss continuous delivery on a full-stack JavaScript stack and how today’s DevOps and Test-Driven-Development processes have enabled the seismic shift in best practices from frequent delivery to continuous delivery. Nick will present an updated maturity model for shifting to continuous delivery and Xiyang will share best practices learned on several rangle.io projects.

Nick and Xiyang from rangle.io on continuous delivery – both the benefits of it, and what it takes to do it. Important things I remember from a week afterward:

  1. Continuous delivery not only requires the right tools and software, but discipline and commitment from a team of developers
  2. Moving a product development team from using bad development and deployment practices to using continuous delivery can take over a year
  3. Continuous integration with unit tests and E2E tests is an important step in that process
  4. Rolling back an application to a previous build should be as simple as deploying a new build

Nick is inspired by Six Sigma techniques when thinking about minimizing variances and improving the efficiency of development when moving a project towards continuous integration.

Continuous Delivery for Modern JavaScript Applications

Wednesday, Jul 2, 2014, 7:00 PM

MaRS Commons
101 College St. Suite 230 Toronto, ON

25 Full Stackers Went

Nick and Xiyang will discuss continuous delivery on a full-stack JavaScript stack and how today’s DevOps and Test-Driven-Development processes have enabled the seismic shift in best practices from frequent delivery to continuous delivery. Nick will present an updated maturity model for shifting to continuous delivery and Xiyang will share best prac…

Check out this Meetup →