# Questions with New development workflow

**URL:** <https://community.forestadmin.com/t/questions-with-new-development-workflow/5385>\
**Category:** Help me!\
**Created:** [October 15, 2022, 9:13am UTC](https://community.forestadmin.com/t/questions-with-new-development-workflow/5385 "2022-10-15T09:13:17Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![Louis-Marie](https://avatars.discourse-cdn.com/v4/letter/l/258eb7/32.png) [@Louis-Marie](https://community.forestadmin.com/u/Louis-Marie)\
**Post date:** [October 15, 2022, 9:13am UTC](https://community.forestadmin.com/t/questions-with-new-development-workflow/5385/1 "2022-10-15T09:13:17Z")

</div>

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:  
 ![image](https://europe1.discourse-cdn.com/flex013/uploads/forest/original/2X/0/04e9ac20614d6e2554c437499acf01e87f149218.png)

**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](https://docs.forestadmin.com/documentation/reference-guide/how-it-works/developing-on-forest-admin/deploying-your-changes)

- 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`

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

My current setup:

```javascript
  "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

---

<div class="post-metadata">

**Author:** ![anon39848301](https://avatars.discourse-cdn.com/v4/letter/a/b9e5f3/32.png) [@anon39848301](https://community.forestadmin.com/u/anon39848301)\
**Post date:** [October 17, 2022, 7:22am UTC](https://community.forestadmin.com/t/questions-with-new-development-workflow/5385/3 "2022-10-17T07:22:12Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Louis-Marie](https://avatars.discourse-cdn.com/v4/letter/l/258eb7/32.png) [@Louis-Marie](https://community.forestadmin.com/u/Louis-Marie)\
**Post date:** [October 17, 2022, 7:52am UTC](https://community.forestadmin.com/t/questions-with-new-development-workflow/5385/5 "2022-10-17T07:52:16Z")

</div>

Hi @anon39848301

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

---

<div class="post-metadata">

**Author:** ![anon39848301](https://avatars.discourse-cdn.com/v4/letter/a/b9e5f3/32.png) [@anon39848301](https://community.forestadmin.com/u/anon39848301)\
**Post date:** [October 17, 2022, 8:12am UTC](https://community.forestadmin.com/t/questions-with-new-development-workflow/5385/6 "2022-10-17T08:12:24Z")

</div>

> 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

 ![image](https://europe1.discourse-cdn.com/flex013/uploads/forest/original/2X/f/f5bea172fbf89be6e6afb0352ea33fde574c6989.png)

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 🙏

---

<div class="post-metadata">

**Author:** ![Louis-Marie](https://avatars.discourse-cdn.com/v4/letter/l/258eb7/32.png) [@Louis-Marie](https://community.forestadmin.com/u/Louis-Marie)\
**Post date:** [October 17, 2022, 12:15pm UTC](https://community.forestadmin.com/t/questions-with-new-development-workflow/5385/7 "2022-10-17T12:15:19Z")

</div>

hi @anon39848301,

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

---

<div class="post-metadata">

**Author:** ![anon39848301](https://avatars.discourse-cdn.com/v4/letter/a/b9e5f3/32.png) [@anon39848301](https://community.forestadmin.com/u/anon39848301)\
**Post date:** [October 17, 2022, 12:42pm UTC](https://community.forestadmin.com/t/questions-with-new-development-workflow/5385/8 "2022-10-17T12:42:01Z")

</div>

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

 ![image](https://europe1.discourse-cdn.com/flex013/uploads/forest/original/2X/8/8325d99971494324b37bdded51331962b43f421c.png)

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”)

 ![image](https://europe1.discourse-cdn.com/flex013/uploads/forest/original/2X/8/857c2d8bdc53523dd36a7d86ef13d5f7a6793007.png)

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

 ![image](https://europe1.discourse-cdn.com/flex013/uploads/forest/original/2X/5/56196dc960ef5f897ad657cf90a33818ff4e1dbe.png)

`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.

---

<div class="post-metadata">

**Author:** ![morganperre](https://dub1.discourse-cdn.com/flex013/user_avatar/community.forestadmin.com/morganperre/32/1296_2.png) [@morganperre](https://community.forestadmin.com/u/morganperre)\
**Post date:** [October 17, 2022, 1:43pm UTC](https://community.forestadmin.com/t/questions-with-new-development-workflow/5385/9 "2022-10-17T13:43:58Z")

</div>



---

<div class="post-metadata">

**Author:** ![Louis-Marie](https://avatars.discourse-cdn.com/v4/letter/l/258eb7/32.png) [@Louis-Marie](https://community.forestadmin.com/u/Louis-Marie)\
**Post date:** [October 25, 2022, 11:55am UTC](https://community.forestadmin.com/t/questions-with-new-development-workflow/5385/10 "2022-10-25T11:55:18Z")

</div>

Hi @anon39848301

Sorry for my late answer.

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

> [@anon39848301](#):
>
> 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

> [@anon39848301](#):
>
> `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