Best practices for staging & prod environments, like a pipeline, using blueprints

5

I’m just going to add a 3rd option here as well that we do see customers deploying that might be of interest to the wider audience.

Alternative 3: Different repo and different render.yaml for environments

This one can be tricky to explain but I’ll try and break it down into small pieces.

A question we often get is how can I have production, staging and preview environments but I want to use different plans between production and staging/preview environments and possibly different settings for staging/previews etc.

So here’s how you can achieve this.

Because a render.yaml can have explicit repo/branch attributes you use this to your advantage.

First up, I’m going to make some assumption here as well as setup a scenario

  • acme\mywidgetsite is the repo where the development takes place
  • master branch is where PRs are merged into
  • render.yaml in this repo is set up WITHOUT repo/branch attributes

So given this, and PR’s to this repo would create a preview environment, I’ll also assume that this is probably what you already have setup in place now. This is going to become your new staging environment.

So now, what you do is create a new repo in Github - call it mywidgetsite-production for arguments sake. All this repo needs is a render.yaml and probably a readme.md to explain why it exists in the first place. You can use your original render.yaml as a starting point but now any of the services that don’t specify a repo/branch will add one:

previewsEnabled: false
services:
   name: mywidgetsite-production
   repo: acme\mywidgetsite
   branch: master
   autoDeploy: false
   ...
...

and now, when you create a new blueprint from the dashboard for your production services (you can also use Annie’s alternative 2 from above here as well to separate production/staging) this blueprint will ALWAYS deploy your master production of the original repo and won’t have previewsEnabled and to trigger a deployment you’d have to trigger the deployment yourself manually.

Once you’ve got your separate blueprint instances setup like (you may have to move a custom domain/DB backup etc) this you can make any changes to the one in the original repo like adding previewPlans, staging config etc and they would only apply to preview environments from what has now become your staging environment. When PRs are merged they would be auto deployed from the master branch to your staging service and then when you want them in production you would have to manually deploy (or hit the deploy hook URLs) the services created by the other blueprint.

3 Likes