Questions with New development workflow

[Louis-Marie]

Hi team,

This week, I ran the latest version of your development workflow with last version of forest-cli (forest-cli/3.0.1 win32-x64 node-v14.20.0).

I have had some problems, so I would like to share my experience return, and ask some advices on the right way to follow the development workflow up to the deployment in production.

I have three different environments:

• Development
• Staging
• Production

The way we make the layout changes si standard:

With the old release, I used to :

• create my branch in my Development environment => forest branch <my_branch>
• push my changes on the Staging environment => forest push
• deploy my new layout in Production => forest deploy

Now, with the last release, I had some problems:
Reference document: Deploying your changes - Developer guide

• I was able to create my branch in the same way, no issue.

• I had an issue to push my changes on the Staging environment.
  When running forest push, it did not work.
  => it complained stating that my Staging environment was not my Origin

  So I had to run forest set-origin Staging first,
  and then the forest push statement ran successfully.

  => is it the right way to do it?

• For the deployment, from my Development environment,
  I was unable to run forest deploy
  => it complained stating that there were no active branch.

  I had to click on the Deploy link in the Forest layout interface.

  Why couldn’t I deploy from the command line?
  is there another way to do it from the command line?
  or did I miss something?

My current setup:

  "meta": {
    "liana": "forest-express-sequelize",
    "liana_version": "8.5.12",
    "stack": {
      "database_type": "multiple",
      "engine": "nodejs",
      "engine_version": "14.20.0",
      "orm_version": "5.22.3"
    }
  }

Thanks in advance for your help

Best regards
Louis-marie

[jeffladiray]

Hi @Louis-Marie

Thanks for your feedback

I’ll do my best to answer all your issues:

I was able to create my branch in the same way, no issue.

You also selected an origin when creating your branch?

• I was able to create my branch in the same way, no issue.
• I had an issue to push my changes on the Staging environment.
  When running forest push, it did not work.
  => it complained stating that my Staging environment was not my Origin
  So I had to run forest set-origin Staging first,
  and then the forest push statement ran successfully.
  => is it the right way to do it?

With our branch origin feature, it is
You should also be able to directly create your branch via forest branch "your branch" --origin Staging to prevent having to set-origin Staging. You can switch origin using set-origin as much as you want. Changing the origin allow you to preview exactly what will be showed after a push/deploy.

For the deployment, from my Development environment,
I was unable to run forest deploy
=> it complained stating that there were no active branch.
I had to click on the Deploy link in the Forest layout interface.

You should also be able to run FOREST_ENV_SECRET=<The env secret of your staging environment> forest deploy.

Branches are auto-close on push/deploy (It was already the case before the branch origin feature recently introduced), that explain why the error message states that you didn’t have action branch (On your development environment).

As a side note, you should also be able to select the origin of your Staging environment to your Production from your environment settings.

Here is quick example, in your setup, of what the development workflow could look like:

• forest branch my-feature --origin Staging → Creates a branch with Staging as the origin.
• Edit your layout
• forest push → push your my-feature branch to Staging
• Check on staging that everything works
• FOREST_ENV_SECRET=<The env secret of your staging environment> forest deploy

At any staging of these commands, you’ll see exactly what you are about the push/deploy. As these commands are now run based on the FOREST_ENV_SECRET and don’t take any parameters (As they will also respect all the origins), they can easily be run in a CI/CD context.

Our development workflow branch origin feature is quite recent, so don’t hesitate to ask if anything is unclear. In parallel, I’ll check the documentation to see if we can improve it with your feedback to make it clearer.

[Louis-Marie]

Hi @jeffladiray

Thank you for your answers.

One thing that is still not clear for me, is the impact on the layout when choosing the origin.
What I need to be sure of is to take the production layout as a reference to work on when creating the branch.

You should also be able to directly create your branch via forest branch "your branch" --origin Staging to prevent having to set-origin Staging .

But if I need to have the production layout as a base to work on it, I should still take “Production as origin” when creating the branch
=> is it right?

And, following this idea, why should I switch the origin to Staging, before pushing my new layout changes.

I think that this is the origin notion that makes me confused.

Thanks again
Louis-marie

[jeffladiray]

One thing that is still not clear for me, is the impact on the layout when choosing the origin .
What I need to be sure of is to take the production layout as a reference to work on when creating the branch.

To explain this, I’ll take the following example

Origin of Staging 1 = Production
Origin of remove-chart = Staging 1

The branch remove-chart is created to remove a chart.
After remove-chart branch is pushed on Staging 1, on the update-chart-title:

• forest set-origin "Staging 1" → The chart will no longer be displayed (As “Staging 1” is now the origin and the remove-chart branch was already pushed to this environment)
• forest set-origin "Production" → The chart is still displayed, as Staging1 isn’t deployed yet.

And, following this idea, why should I switch the origin to Staging, before pushing my new layout changes.

The overall objective of branch origin is to allow you to see exactly on screen what you are about to push or deploy, so you only need to set-origin to Staging if you want to push to it.

But if I need to have the production layout as a base to work on it, I should still take “Production as origin ” when creating the branch

Exactly, but you’ll not be able to push your changes on Staging then.

Even if we don’t really like the analogy (Because the behavior not exactly the same), you can see branch origin just like git branches, and set-origin as a kind of simple “rebase”.

I hope this is clearer with this explanation, otherwise, please let me know

[Louis-Marie]

hi @jeffladiray,

Yes, I think this is clearer now.

so, if I want to:

• pull the layout from the Production
• push to Staging
• deploy to Production

=> I understand that it imposes us to have the Staging environment up to date with the Production one, in order to be able to have the Origin on the Staging environment.

And we will be able to follow the process:

• forest branch my-feature --origin Staging → Creates a branch with Staging as the origin.
• Edit your layout
• forest push → push your my-feature branch to Staging
• Check on staging that everything works
• FOREST_ENV_SECRET=<The env secret of your staging environment> forest deploy

However, it could impact our way of working, as we used to push on Staging and make some adjustments when needed. If another dev wants to start working at that point in time (before the first dev has deployed his changes), the Production is the only one which is “clean”, and it is then not possible to push on Staging, because it will not be up to date with the Production.

I am afraid it’s a bit tricky to work with this new development workflow.
This is even more risky than the previous release.

It may be another debate, but I would have started from the following principle: if I push a layout to Staging, it is my layout that matters, not the environment from which it was built on (the famous origin ).

So, as much as I understand these different operating principles, I remain annoyed by its implementation.

Unless, I am still wrong somewhere

Thanks
Louis-Marie

[jeffladiray]

I’m still convinced that our branch origin feature allow you to achieve just what you said, but maybe I mis-undertood your point.

Here’s another representation of what could be achieved

In your previous workflow, you were always based on production, but still pushing to your staging, the side effect being that some changes may already be on your staging environment that you weren’t able to see (In your case, L3 = L1 + all the manual fixes that were done on your development environment).
When you did a push, the result on staging 1 could be unexpected.

You can still achieve the same result (If that’s your prefered way of working) by creating a branch based on production, then switch the origin to staging. (forest branch xxx --origin Production & forest set-origin Staging when you want to push). It is an extra command compared to the previous version of the development work, however you can test what will be pushed on staging locally.

if I push a layout to Staging, it is my layout that matters, not the environment from which it was built on (the famous origin ).

All the layout changes are tracked on an individual branch basis, so switching origin will never “break” anything that was done on the branch.

A concrete example could be the following:

(“Staging” is the origin of “Your feature branch”)

(“Production” is the origin of “Your feature branch”)

set-origin only gives you more control of where your layout changes needs to be propagated + allow you to preview directly what you push or deploy.

I may have missed something in your use case though, so don’t hesitate to correct me if I’m wrong.

[Louis-Marie]

Hi @jeffladiray

Sorry for my late answer.

To come back to you, here is what was missing in my previous understanding:

@jeffladiray

All the layout changes are tracked on an individual branch basis, so switching origin will never “break” anything that was done on the branch.

and

@jeffladiray

set-origin only gives you more control of where your layout changes needs to be propagated + allow you to preview directly what you push or deploy.

So this is clear for me now.

I think that the term origin might have confused me. In fact, it could have been named destination (= where we push the layout changes).
But that’s ok now.

Thank you very much for your explanation.

Kind regards
Louis-Marie