Suggested approach to environment releases

Hi :evergreen_tree:

When you have multiple developers, working in the same environment - any change you make on your end, eg. introduction of a new collection, which is not yet sourcecontrolled to the others, ends up being a struggle. Even if they are on a localhost too, the UI configurations are shared across instances, so any change you make, ends up being removed when someone else runs their localhost. Quite unintuitive as far as ‘localhost’ goes. It seems that you can create personalized versions of an environment, by just copying the current eg. development out to a branch, that you can then work on yourself. This should be fine.

My question is then, how do you migrate all of these changes back to development? You couldn’t just make development a copy of your local copy, as anyone else doing it afterwards, would then override your changes.

I guess this could be solved by working on your local instance, then applying the changes when you are happy with them, to the development. That works fine - until someone doesn’t have the newest version, and accidently runs a localhost in the development environment – then everything gets messed up. This have happened quite a few times to us.

A second question,
How do you suggest we go about rolling changes from development up to staging, and production. We can’t trust an upstream, by simply importing the configuration from development into staging. As development is exactly that, an unstable environment where you could have messed many things up. At the moment our only solution, is to write down the UI changes, we want to roll out, and then manually apply them in the staging environment. This leads to a large manual process, and are prone to errors.

A third question,
Is there any API or automations to this environmental cloning/creating? We would like to occasionally override Development with Staging, so that it always reflect the proper configuration, without all the temporarily development things people tried.

Hi @dequestion

Thanks for your interesting questions.

First important thing to have in mind to collaborate peacefully on Forest Admin as a development team: each developper should have its own environment on the related project (and thus a different environment secret on their local machines).
It will prevent unexpected schema overide as you described.

About your first and second question, I think we should introduce what we call the “Development Workflow”.
It is a new feature that provides a much better developer experience in these kind of situations.
It is in beta test right now but it could be great if we could add your project to the beta batch.

About automation concerns, you could use our CLI to manage environments programatically.
Some of our customers use it for CI/CD purposes.
Here is the repository: GitHub - ForestAdmin/toolbelt: 👾 The Lumberjacks' toolbelt is the Forest CLI which makes easy to manage your back office application directly from the terminal.

I hope it helps.

Hey @deequestion :wave: , and thanks @arnaud for the detailed explanation.

Indeed, we’ve been working lately on a new feature - the Developer Workflow - to facilitate developers’ collaboration on our platform. It’s already live in Beta, and I’d love to get your feedback.

I’ve just sent you a private message if you’re interested in a demo.

Looking forward to chatting!