Managing multiple environments

#21

There’s great content here. I will leave here also how we do it (similar to @aswinmohanme):

build-and-deploy:
  name: Build and deploy
  runs-on: ubuntu-latest
  needs: 
    # (...)
  steps:
    - uses: actions/checkout@v2

    - uses: superfly/flyctl-actions/setup-flyctl@master
    
    - run: flyctl -a our-app-staging deploy --remote-only
      if: github.ref == 'refs/heads/develop'
      env:
        FLY_API_TOKEN: ${{ secrets.FLY_API_TOKEN }}

    - run: flyctl -a our-app-production deploy --remote-only
      if: github.ref == 'refs/heads/main'
      env:
        FLY_API_TOKEN: ${{ secrets.FLY_API_TOKEN }}

Locally there’s a handy env var FLY_APP (ex: export FLY_APP=our-app-name) , you could also pass -a our-app-name on every fly command or

1 Like
#22

I like the idea of having the two scripts. But I was also thinking having something akin to the Heroku piplines could be nice.

#23

A caveat: This -a <staging-or-prod> trick doesn’t work with Machine apps (yet): Preview: Deploying applications on Machines with flyctl - #6 by ignoramous

Well, “pipelines” seems to be on Fly’s roadmap anti-roadmap: Rough edges for multi-app services - #2 by kurt

#24

I keep the app name in the fly toml the staging app, and when I want to deploy production I promote the latest staging image to production, so I never build a new image for production, simply deploy one of staging’s images:

#!/usr/bin/env ruby
require "json"

js = JSON.parse(`flyctl image show --json`)
registry = js["Registry"]
tag = js["Tag"]
repo = js["Repository"]
production_app = "app-production"

cmd = "flyctl deploy -i #{registry}/#{repo}@#{tag} -a #{production_app}"
puts "----> Running #{cmd}"
system(cmd)
1 Like
#25

Ah, similar to: Deploy fly apps using custom made bot - #3 by kurt

This works because I guess you must have already deployed the required config (aka fly.toml) to prod at least once?