Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Running Strapi in production and version control sync #1986

Closed
greatwitenorth opened this issue Sep 19, 2018 · 18 comments
Closed

Running Strapi in production and version control sync #1986

greatwitenorth opened this issue Sep 19, 2018 · 18 comments
Assignees

Comments

@greatwitenorth
Copy link
Contributor

@greatwitenorth greatwitenorth commented Sep 19, 2018

Informations

  • Strapi version: 14alpha

This is more of a question about best practices for running Strapi in a live environment (yes I know it's alpha, but this will presumably apply to the final release as well).

I noticed that Strapi generates new files when a content type is added. This means that the production environment's files will become out of sync with version control. Is there a recommended deployment process? Am I supposed to commit changes from production to my git repo after making changes in the admin? Is there a recommended way of deploying changes (i.e. should I not be creating new content types in production)?

@emadicio

This comment has been minimized.

Copy link

@emadicio emadicio commented Sep 19, 2018

If you run your app with NODE_ENV=production you'll notice that plugins that actually edit or create files are disabled. So that means you cannot create or edit content types in prod

@greatwitenorth

This comment has been minimized.

Copy link
Contributor Author

@greatwitenorth greatwitenorth commented Sep 21, 2018

OK that's good to know. I am still seeing files being changed and generated in production though. Here's what a git status on the server yields:

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   admin/package-lock.json
	modified:   package-lock.json

Untracked files:
  (use "git add <file>..." to include in what will be committed)

	config/locales/de_de.json
	config/locales/en_us.json
	config/locales/es_es.json
	config/locales/fr_fr.json
	config/locales/it_it.json
	config/locales/ja_jp.json
	config/locales/ru_ru.json
	config/locales/tr_tr.json

Should I file this as a bug then? Or is this intended behaviour?

@Downloaddave

This comment has been minimized.

Copy link

@Downloaddave Downloaddave commented Sep 21, 2018

Hey there! Thanks! This is good to know.

I had deployed Strapi locally then to a Prod environment, and was confused since I didn't see the content-type-builder in the production CMS.

I'm trying to understand the deployment and update process as well...

This is where it seems like it's leading to me:

  • Developer sets Strapi up locally
  • Creates content-types using the content-type-builder
  • Strapi makes updates to the file structure locally and on the local MongoDB
  • On production we will have to push both the code and db updates?

I understand that making changes to the content-type-builder reboots the service, and we don't want production to go down during the rebuild, but it seems like data would get really out of sync between production and development.

I'm not sure if that's the correct workflow, if I'm completely misunderstanding, or if that was what was envisioned.

@Downloaddave

This comment has been minimized.

Copy link

@Downloaddave Downloaddave commented Sep 25, 2018

Would it make more sense for all plugins to be enabled, but only admin or super admin has the ability to make updates to the content-types (that require a restart) and a warnings that updating them will restart the Service?

@Aurelsicoko

This comment has been minimized.

Copy link
Contributor

@Aurelsicoko Aurelsicoko commented Oct 2, 2018

You're right! The Content-Type Builder is a development plugin. His goal is to speed up the development of your project. It should not be used in production. We didn't design this plugin like for this usage.

The real pain is to migrate the development configuration to production, and vice-versa. We plan to offer a new command with the CLI called strapi migrate to easily migrate from an environment to another. I can't give you a release date though...

@cschweda

This comment has been minimized.

Copy link

@cschweda cschweda commented Nov 29, 2018

+1 on the strapi migrate.

I'm not entirely clear what the version control process is. One thing I did -- since I use a non-local mongoDB instance is to add 'database.json' in all environments to my .gitignore file -- and then create these locally once I've cloned the repo.

And do I set up separate databases for each environment? A 'prod' database with the actual data -- and a 'dev' database with test data?

@Aurelsicoko

This comment has been minimized.

Copy link
Contributor

@Aurelsicoko Aurelsicoko commented Dec 6, 2018

@cschweda Strapi supports multi-environment configurations, so you can use this feature to easily switch between database. However, the configurations stored in the development DB won't be transfered to the production DB. This is why we need the strapi migrate CLI.

If your current workaround works, it's okay. It makes sense to me even if this is definitely not the optimal way to do it...

@lauriejim

This comment has been minimized.

Copy link
Member

@lauriejim lauriejim commented Dec 26, 2018

@lauriejim lauriejim closed this Dec 26, 2018
@maxime1992

This comment has been minimized.

Copy link

@maxime1992 maxime1992 commented Jan 12, 2019

So how to do it now, until the CLI gets available?

I've been developing locally using strapi and I'm now trying to push to production but I feel completely stuck 🤷‍♂

The real pain is to migrate the development configuration to production

Even if it's painful, is there a description of how to do it for now?

@ccll

This comment has been minimized.

Copy link

@ccll ccll commented Jul 3, 2019

@Aurelsicoko I couldn't find any useful answer from those materials (about migrating schemas/content-types between dev/staging/production environments). Am I missing something?

@Aurelsicoko

This comment has been minimized.

Copy link
Contributor

@Aurelsicoko Aurelsicoko commented Jul 5, 2019

@ccll If you are using Git, you can easily track the changes in the content-types files. However, it becomes complicated if you have customised the layout of the content type because it means that you have to export your database and import it to the production database. We know that the data might not be synchronised between both environments, so you have to only dump the core_store (where the settings are stored) table and only migrate this table.

@ccll

This comment has been minimized.

Copy link

@ccll ccll commented Jul 8, 2019

@Aurelsicoko Thanks, I'll check the core_store table.

Normally in my other apps I migrate DB with tools like db-migrate, where DB schema migration actions are scripted in text format and version controlled with Git (then transferred and replayed between multiple dev/staging/production environments), but my first attempt to use db-migrate with Strapi failed due to incompatible format of database.json file. Would you please give some suggestions on this respect?

@rjain15

This comment has been minimized.

Copy link

@rjain15 rjain15 commented Jul 10, 2019

I have similar questions, I am doing local dev (mongodb, docker) and I am deploying in production in kubernetes. What do I need to move from dev to production? What is the migration path? My content writer is writing in production, when I migrate what gets overwritten and what is not?

@mastix

This comment has been minimized.

Copy link

@mastix mastix commented Jul 11, 2019

Same thing here. I'm currently evaluating Strapi for my requirments (against other headless CMS) and currently I have problems figuring out how the correct development - production lifecycle looks like. Actually I'm planning to run strapi from within a Docker container, so integrating everything (Docker, git (push hooks), updates,...) is kind of unclear to me.

@KevinKelbie

This comment has been minimized.

Copy link

@KevinKelbie KevinKelbie commented Jul 13, 2019

Here is a workflow I was thinking about using.

  • Setup a production server and a development server on a subdomain
  • Make changes to Strapi on the development server
  • Developer commits changes from the development server to version controll
  • Developer pulls changes onto production server

Downside is that you won't be able to see instant changes on the production server and would have to wait for a developer to apply the changes.

@vishwa-

This comment has been minimized.

Copy link

@vishwa- vishwa- commented Feb 26, 2020

As many of you posted above, I am evaluating strapi and few more tools. One of the important features is migration of content from staging to production. Is strapi migrate available?

@lauriejim

This comment has been minimized.

Copy link
Member

@lauriejim lauriejim commented Mar 6, 2020

Hello this feature is not planned for the beginning of 2020.
Here is the item in the roadmap - https://portal.productboard.com/strapi/1-public-roadmap/c/12-migrate-across-environments

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.