Any updates to best practices staging/production pipeline?

1

Hi there,

I was just reviewing this thread, which hinted that Render may be rolling out something of a staging => prod pipeline. Since the initial comment was about 7 months old, I figured I’d ask if there had been any updates?

I am specifically trying to do the following:

  • Have nearly identical infrastructure for staging and production environments. Only differences would be in the plans attached to the services (i.e. staging can be much weaker).
  • Have completely different env secrets for staging and production.
  • When code is merged into main, I want automatic deploys to both staging and prod.

I see that this can be done by putting lots of duplicate services into render.yaml. However, that has some downsides, most notably, if I want to change something about staging, it forces a deploy to prod, which is no bueno. In this thread you mentioned potentially allowing different render files. Have you made any progress on this?

Thanks,

Evan

2 Likes
2

@anniesexton I saw you commented on the original thread. Tagging you here in case you have those updates?

3

Use Blueprint Instances to deploy the same render.yaml file twice ?

4

deploy the same render.yaml file twice

That doesn’t work for my use case. I want staging and prod to have the same components (Redis, Postgres, Web worker, job worker). However, I want them at different plans, i.e. staging doesn’t need to be as robust as prod.

You can look at Terraform’s Input Variables to see an example of how other folks have accomplished this.

It might be worth stating my overall goals: I want to be have a staging and prod environments that are effectively identical. The only things that will be different are the environmental variables and the specific underlying hardware (e.g. the plan). When I need to make changes to prod, I will want to be able to test these on a staging environment first.

5

We do plan on some enhancements around this but nothing immediate.

A common scenario to this is as follows.

The present repo with your render.yaml in becomes your staging environment.

You create a new repo with a single render.yaml in - this can be based off the original one but in this specify repo and branch attributes explicitly. You can also override plans, env vars etc.

Create a new team (this keeps the production/staging environments separate) and create a new blueprint based off this new repo. Because you’ve explicitly set repo and branch then this blueprint will only ever deploy those versions.

The one problem though is you specify

When code is merged into main, I want automatic deploys to both staging and prod.

That’s a problem, as in this setup, both staging and production would deploy when you merge into main. The solution to that would be to have staging use a specific staging branch so this is auto-deployed to staging and then when that is merged into master it’s deployed. Of course, this introduces another branch, without having separate branches the option would be to manually deploy main to production when you’re wanting to deploy it - that way, main could auto-deploy to staging as well.

6

I am not quite following here. Imagine my main repo is called webApp. That’s where all my code lives. When I create a new repo (webAppProd), do I fork all of my code? I can’t imagine that is what you’re actually suggesting, because it would create a lot of overhead in terms of syncing commits between two repos.

Or are you saying that webAppProd knows to pull the source code from webApp? This seems to initially make more sense, but then it creates all sorts of problems around CI/CD. For example, let’s say I want to automatically deploy to prod after CI passes on main. Would webApp call to webAppProd to notify of a successful build?

I feel like I must be missing something, because I cannot make the ergonomics make sense.

7

Definitely the second - the only file in the second repo is render.yaml and that explicitly has ‘repo’ and ‘branch’ set the original repo for each of the configured services.

I don’t think you’re going to get the perfect setup that you want - right now.

The auto deployment from ‘main’ would fire for both environments, which would be bad. In my last paragraph I suggested a ‘staging’ branch. So the flow would be…

Staging environment auto deploying staging.

  • Preview environments here etc merged into staging.

When finished, staging merged into main,

Production environment auto deploying main

if you don’t want to introduce a staging branch, then you have to disable auto deploys to production and then manually trigger a deployment to production when you want to put code live.

John B

8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.