Graphql-engine: Migrating between different couple environment

[Fortidude]

I understand how migrate works (I guess) from the docs. I can run my remote hasura project from heroku by hasura console and do some changes. I can see the up.yaml and down.yaml.

But let's say we have 3 different environments (three different instances):

• local debug (docker)
• heroku staging (internal tests)
• heroku production

Now I as a dev do some changes in local postgress. New database, relations etc. After that I want to somehow migrate those changes into heroku staging - see if everything works and then migrate it into another heroku production instance.

As I see I can't use hasura migrate, e.g.:

• local docker (table: profiles)
• heroku staging (table: profiles)

now I do some changes into local docker and run:
hasura init --endpoint http://localhost // docker
hasura migrate create "init" --from-server

this gives me the .sql and .yaml file.

After that I'm trying to run:
hasura migrate apply --endpoint https://my-app-staging=herokuapp.com --admin-sected <secret>

but that gives me an error:

`{
"sql": "CREATE TABLE public.profiles (\n id integer NOT NULL,\n name text NOT NULL\n);\nCREATE SEQUENCE public.profiles_id_seq\n AS integer\n START WITH 1\n INCREMENT BY 1\n NO MINVALUE\n NO MAXVALUE\n CACHE 1;\nALTER SEQUENCE public.profiles_id_seq OWNED BY public.profiles.id;\nCREATE TABLE public.test (\n id integer NOT NULL,\n name text\n);\nALTER TABLE ONLY public.profiles ALTER COLUMN id SET DEFAULT nextval('public.profiles_id_seq'::regclass);\nALTER TABLE ONLY public.profiles\n ADD CONSTRAINT profiles_pkey PRIMARY KEY (id);\nALTER TABLE ONLY public.test\n ADD CONSTRAINT test_pkey PRIMARY KEY (id);\n"
}

[42P07] FatalError: relation "profiles" already exists`

Question - is there any way that I'm missing to sync 2-3 environment?

[GavinRay97]

It sounds like you're dumping the entire state of the database on each migration, which means it's trying to create all of the previous tables each time in the migrations.

You can use init --from-server to dump the entire state of the DB each time, if your app is not in production yet, but to apply it, you need to drop the DB you want to migrate it on. This works well in workflows like k8s/local docker-compose where you can just delete and recreate the service, but not so much on platforms like Heroku.

The intended use of init --from-server is to dump a migration that contains the state of the DB, because you weren't interacting with Hasura through the CLI and having it auto-generate migrations for each action you perform in the console.

After you do an initial init --from-server, you have to either:

• Interact with Hasura through the CLI so that it generates migrations only from the current init migration tables -> forward (so no duplicates)
• If you want to continue using init --from-server and having a single migration, the migration needs to be applied on a fresh DB so that it doesn't conflict with existing tables.

[joshuarobs]

Did you manage to find out a way to do this? I'm also trying to do this but to no avail

[rikinsk]

As @GavinRay97 had mentioned, you should probably be generating migrations incrementally and not do the init --from-server step each time. We have a guide to set up migrations here. _(This is for the older migrations version but all the concepts apply. A version of this guide for the newer migrations version is in the works)_