`forest deploy` not working as expected?

Help me!
1

I had a Production environment.
I had a Staging environment based upon my Production environment.
I had a Dev environment based upon my Production environment.

I made a change on my Dev environment without creating a branch.

Because I wanted to maintain my traditional workflow, I ran forest set-origin Staging which changed the basis of the Dev environment from Production to Staging (verified in UI).

I ran forest branch to create a branch (yes, retroactively :grimacing:).

forest push pushed changes to Staging which agrees with the diagram in the documentation

Tested in Staging environment.

According to the documentation, forest deploy should then take those changes on the branch and deploy them to Production but I got Cannot "deploy" to non-reference environment, please use "push"

What am I missing? I don’t see a CLI command that will change my environment so that I can deploy from Staging.

I was able to use the deploy to Production feature in the UI and the changes are now live but I’d really like to understand the “correct” way. Also, this was simply adding a collection but we have some more complex changes planned and I’d like to get the hang of this dev flow before moving on.

2

Hey @Brett_Belka :wave:

forest push and forest deploy uses your current FOREST_ENV_SECRET to determine what to push/what to deploy.

It should be present in our documentation, but this point has been raised multiple time recently, so I guess it’s not visible enough.

“Deploy to production” on the UI is equivalent to FOREST_ENV_SECRET=<The env secret of staging> forest deploy. Again, this was done to ease CI/CD integration.

Let me know if that helps.

3

Hey @jeffladiray

The explanation makes sense, but I think the implementation could maybe use some tweaking. The current setup makes sense for push but deploy needs tweaking.

With, what I would think is a fairly standard workflow, where you have a Dev (local), Staging (remote), and Production (remote) environment, I shouldn’t need to change an env variable to a value that’s not indicative of my current environment in order to deploy to production. It seems like forest deploy should accept an “origin_environment” option or something of that nature. The only proper way that I have to deploy staging to production is in the UI - which runs contrary to this CLI model we’re trying to use.

Part of what I’m working on right now is internal documentation that’s specific to our preferred processes regarding FA. Being required to jump back and forth between CLI and UI is confusing.

4

Thanks a lot for your feedback. With both of your threads about Development Workflow, this leads me to think that our documentation could be more complete on all these elements.
I’ll push your insight on our product board.

I’ll also do my best to justify the choices that were made here:

With, what I would think is a fairly standard workflow, where you have a Dev (local), Staging (remote), and Production (remote) environment, I shouldn’t need to change an env variable to a value that’s not indicative of my current environment in order to deploy to production

With the current workflow, you could:

  • Set the origin of staging to be production (either via the forest set-origin command, or via the UI)
  • Set the origin of your development environment to be staging.

Then,

  • forest push with the development environment secret would push changes to staging
  • forest deploy from the staging environment/using the staging environment secret would then deploy all the changes on staging onto production.

In case you want to deploy from dev to production, you could:

  • Set the origin of your development to be production (either via the forest set-origin command, or via the UI)
  • forest deploy

The set-origin command is handy here, as you can dynamically choose on which environment you want to deploy your Layout Changes. This command also allow you to exactly preview what you are about to deploy.

It seems like forest deploy should accept an “origin_environment” option or something of that nature

Allowing such command would mean that you would have no idea of what is going to be changed/deploy exactly. A more in-depth example is available here.

The only proper way that I have to deploy staging to production is in the UI

FOREST_ENV_SECRET=<staging env secret> forest deploy should work as well

The only limitation that we currently have is that creating a branch and pushing this branch to a Staging/deploying a branch to a production while on a development environment is only possible via the CLI.

I really hope I made it clearer, but if that’s not the case, just let me know.

2 Likes
5

@jeffladiray

Thank you!

I think understand how it works now. You’ve done a great job of explaining the eccentricities.

My main point is that my Dev environment is the local environment. Staging is remote. Changing the FOREST_ENV_SECRET in my local .env to a value that is meant to indicate a remote environment (which is currently running elsewhere) doesn’t make sense. What happens when someone changes it in this manner to deploy and forgets to change it back before running the project locally again?

I think the CLI tool could be great and, in may ways, is. But having to go to the UI to get a different value that you have to change in the .env for the sole purpose of running forest deploy renders the forest deploy command kind of useless. We’ll just click Deploy to Production (I think that’s what it said…) instead of all that copy pasta…

Allowing such command would mean that you would have no idea of what is going to be changed/deploy exactly. A more in-depth example is available here 1.

This chart seems incomplete. Dev is it’s own env and the feature branches are branches off of Dev. I wouldn’t branch Staging.
forest deploy {origin_env} would only be valid for environments based on Production.
To develop a feature, branch Dev, make changes, push branch to dev, test, push dev to staging, test, deploy staging to production.

6

Hey @Brett_Belka :wave:

(Sorry if my previous response feels like I’m trying to justify our feature here - my goal is strictly to understand what you perceive as a limitation here, to see either what we can do in our documentation to make it clearer, or what needs to evolve in the future about Development Workflow :slight_smile: )

Ok so I think I start to understand what your limitation is here.

You are indeed not supposed to change your FOREST_ENV_SECRET to the staging one. The command I shared (FOREST_ENV_SECRET= forest deploy` is only meant to be used in an automated workflow (Like a CI/CD pipeline, when you deploy your staging code to your production). That’s the reason why we provided a “Deploy to production” directly in the UI, where it feels “natural” to click once you made all your tests on your staging environment.

To develop a feature, branch Dev, make changes, push branch to dev, test, push dev to staging, test, deploy staging to production.

Changes made on a branch on dev are automatically pushed to the dev environment.

  • forest branch --origin=Staging feat/my-feature “rebase” your development environment branch on Staging - so if someone else already pushed to staging, you’ll get their Layout Changes on development as well.
  • forest push pushes to staging.
  • Go on staging & test, and once everything works
  • Click “deploy to production”

Allow you to keep the workflow you described. In your case, forest xxx commands would then just be used for your development environment.

I still have a quick question though. As I stated earlier

The only limitation that we currently have is that creating a branch and pushing this branch to a Staging/deploying a branch to a production while on a development environment is only possible via the CLI.

Would a full UI experience (Creating your development branch and pushing your branch to staging via the UI) suit your need here? You wouldn’t have to use the CLI for such flow then.

Still, I’ll push your forest deploy <Origin> to our product board.

Again, Thanks for your great feedback :pray:

7

Sorry if my previous response feels like I’m trying to justify our feature here

Not at all - this feels like a constructive conversation.

forest deploy is only meant to be used in an automated workflow (Like a CI/CD pipeline, when you deploy your staging code to your production)

Got it. This makes way more sense.

  • forest branch --origin=Staging feat/my-feature “rebase” your development environment branch on Staging - so if someone else already pushed to staging, you’ll get their Layout Changes on development as well.
  • forest push pushes to staging.
  • Go on staging & test, and once everything works
  • Click “deploy to production”

Yep. This is what I’ll document on our end.

Would a full UI experience (Creating your development branch and pushing your branch to staging via the UI) suit your need here? You wouldn’t have to use the CLI for such flow then.

I’d probably actually prefer a full-CLI solution. That’s what I was expecting with the new tool, so that why I was so confused. I get it now. Sorry if it took me a minute…

1 Like