Ability to recreate projects (environments) from each other

[e965]

Is your feature request related to a problem? Please describe. I would like to say that the approach you propose, in which it is necessary to create a new project for each environment, is certainly interesting, but not very convenient.

I really like the way 8base does it - you have a parent environment and you can make child branches from it. In this case, by default, data is copied to a new environment, that is, you do not need to bother with setting up some data again (this, for example, is very convenient for testing).

In addition, your flow is tightly tied to branches in git (as I understand it, it is assumed that we have permanent branches / projects for all developers), but if I am running a project where developers do not have their own permanent branches at all, but there are feature branches, this is terribly inconvenient. I really want to be able to FULLY (together with the data) recreate the branch from, for example, staging, and work with it, and after the development of the feature is completed, merge the changes into the parent branch (this is how it works in the git, by the way!), then delete the branch and the project together with it.

Describe the solution you'd like Ability to recreate projects (environments) from each other

Describe alternatives you've considered The previously mentioned 8base that my team is currently using.

[dbarrosop]

I'd like to understand better the workflow and use case because I am not sure I understand it. The workflow nhost recommends is the following one:

1. You create git branches for your environments (i.e. production and staging) and connect nhost projects to them
2. You use git branches where you develop locally using the nhost cli
3. You push to your feature branch, using the nhost CLI in the CI to run tests
4. You merge your feature branch into staging which applies changes in the feature branch
5. You merge staging into production which deploys changes in staging into production

How does your proposal fit or modify this workflow?

[e965]

@dbarrosop I told my view just for context. As I said, the proposed nhost flow is quite interesting. I just would like to see the feature of recreating (branching) one environment from another, along with all the data in the database.

[dbarrosop]

We believe that understanding the use cases and workflows that people want is important as it helps choosing which features are put in the roadmap and how they are built.

For instance, cloning a project for ephemeral testing environments might not work for everybody without manual intervention. If you are using/testing oauth2 authentication you might still need to do manual work to fix that. Also, having to clone several gigs of storage data while you just want to quickly test some new graphql query might be expensive.

Again, I am not arguing against having a "project cloning" feature, as a matter of fact, we have helped users clone projects in the past, I am just trying to figure out what it means in this context.

[e965]

By the way, I mentioned 8base for a reason - we use it, but not everyone likes this solution (due to insufficient stability), and therefore we are looking for alternatives. And as one of them we consider the nhost.

And now to the point. I will try to describe which flow are used in our team. Basic information - we have a production environment (master), from which we create a staging branch at the very beginning. Both of these environments are public, that is, they have a URL.

1. The developer receives a new task, studies the requirements
2. The developer creates (clones) a new environment for this task (via CLI), as well as a new branch in the git. Since the staging already contains some test data (for example, users and related entities), in most cases the developer does not need to worry about doing any additional environment setup.
3. The developer gets the job done
4. When the developer finishes work, he generates migrations, and uploads them along with the code to the branch in git
5. The code is reviewed, and if everything is fine, the task is given for testing
6. The tester, through Github Actions, launches a workflow to deploy the test environment based on the developer's git branch. This workflow recreates the test environment from staging, and deploys new code on top of it, as well as a migration commit. Well, I repeat, the tester, as a rule, also does not need to think about additional environment settings. Also all test environments are public.
7. If errors are found during testing, then the developer makes corrections, and step 6 is repeated anew
8. If everything is fine, then the task goes further, and subsequently it is merged into staging. The branch in the git and the environment created for the task are deleted.

[dbarrosop]

Thanks for clarifying, that makes sense. IMO you should be able to use our current workflow in a similar way.

Hasura has the concept of "seeds" (which you could create from a pg_dump, for instance) and those seeds can be part of the git repo (so everybody would be working with the same set of known data). Now you can use the nhost cli to start your local dev environment and have it load the seeds automatically. So the main difference would be that instead of a public environment you'd have a private one via the nhost cli and that instead of having unknown production data you'd have known data. Working with seeds requires a bit more of upfront work, I agree, but has the advantage you control the data and can easily test edge cases and simplifies writing unit tests (if you know the data you know what to expect).

Anyway, mostly highlighting how your current workflow would map into ours. All in all we agree that cloning/branching projects is a good feature but we don't have it in our immediate roadmap.

[e965]

The idea about seeds sounds interesting, thanks.

But in any case, I hope that the possibility of cloning will someday be implemented 🙂

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.