I'm looking to use Strapi for a client of mine and I was wondering if there were best practices to migrate content from one environment, for example staging to production? My client has a lot of content, so recreating all the content on each environment is not viable.
Thanks a lot !
For now, the only raw solution is to dump your database ...
I think that the best option is to create a module that let you import/export content.
But keep in mind that migrate content between environment is never the best option. Your client probably want to see only the final state, but you probably want test content that use every spec' of your app.
Related
What is the recommended way to deploy changes (for example change in some Content Type model) from development to production without downtime?
I’m using this setup.
I have development instance with development postgres database.
On production I have 3 strapi instances (serving both api & admin, using the same production postgres database) and those instances are behind loadbalancer.
Lets say that I have Content Type named: Article (both on development and deployed on production).
Lets assume that I want to change that content type for example I want to add some fields and remove some fields in Article content type.
How to deploy changes to production without downtime?
I’ve done some tests and when I for example update Strapi Production Instance #1 to pull new code for updated models, strapi will update database of course. And from that time Strapi Production Instance #2 and #3 have problems serving Admin panel for example (javascript errors because database was changes but JS model files are not updated).
After I updated code on instance #2 and #3 everything works as expected.
But doing something like this on “working product” will be visible as downtime.
How to properly handle this situation? Thanks for help!
Could PM2 solve this problem? Strapi mentiones this in their documentation
PM2 Runtime allows you to keep your Strapi project alive and to reload it without downtime.
Strapi Docs v4
Strapi is a powerful tool, but I am unable to find any documentation/instructions which explain about the best practices/strategy to migrate contents from one environment to another, for example Dev to staging to production ?
If you got a lot of content and recreate all the content on each environment is not viable.
Please guide, how to move API and DB (mongo) stuff.
If there is only manual workaround for now, we should document it so that can be used for now.
For now there is no other way than manually import/export your database:
Github issue: Import / export data
I'm fairly new to server administration. I have my Laravel app up and running and I want to make sure it has proper backups. I have researched some backup packages and I have settled on https://github.com/spatie/laravel-backup.
However, once the server fails, I need to know how to use the most recent backup (which will be on AWS S3) to restore the database on the rebuilt server. Are there any suggestions for guides on how to do this? I can't seem to find any unless it doesn't really require much learning and instead just a couple mySQL commands.
Thanks!
I would use replication and within Laravel i would try to switch connection to the replica database server so things can run smoothly until the problem is resolved.
Take a look at this Cross-Region Replication
A typical production environment is automatically running backups on most important things that your deployment needs in order to recover from a failure. Those parts would commonly be your database and storage folder, and configuration files.
Also when you deploy a laravel application there aren't many things that are "worth" backing up , you can choose the entire disk to be mirrored somewhere or you can schedule a backup script which run every N times and backups the things that are more important to your application.
Personally i wouldn't rely on an package from laravel to handle my backups , you can always use other backup utilities, replication and so on.
Update
Take a look at the link below:
User Guide » Amazon RDS DB Instance Lifecycle » Backing Up and Restoring
Backing Up and Restoring
You can call the API function RestoreDBInstanceFromDBSnapshot as showed on example.
But i don't think something automated exists that would auto restore or magically make everything work, you need to do a lot of security checks if something like that would even be attempted. Final word i believe a good solution manually entering or sending the request would be the most solid solution.
Does anyone know about this problem: Any new fields I add work fine in the local back office, but when I use Webmatrix to publish to the server (discountASP.net) fields don't show up. I did a view source in the browser and they're just not there!
For example, #Umbraco.Field("comments")
Thanks!
Daniel
If you add new field, they are only added in the database. That means you would need to update the database on the production website. Webmatrix doesn't do this for you (by default).
There are a few ways to handle this scenario:
copy your database to the production server (i would advice against this, because you might overwrite content and media changes on the production server)
create the fields manually on the production server (easy solution)
use a commercial package like courrier (personally i believe it's a good solution, only if you have a content staging workflow)
use a free package like usync (http://our.umbraco.org/projects/developer-tools/usync)
I've just started learning .NET MVC so this may be a silly question, but I've yet to find a good answer.
I'm following the Code First approach using the Entity Framework to build my database for me. I've included the following in my Application_Start() method in order to allow me to edit my database by making changes to my Model objects.
Database.SetInitializer<ContactManagerDB>(new DropCreateDatabaseIfModelChanges<ContactManagerDB>());
I was just wondering what would happen if I pushed this application to a production environment and then made a few changes to my models and then updated the application? Would this really drop and recreate the database in the production environment?
What's the best practice for pushing changes to production env. using the Code First approach?
DropCreateDatabaseIfModelChanges should only be use early on in development, never on a production machine. If you pushed to a production machine and made schema changes, you'd loose all your data.
You could delete the EdmMetadata table in your production environment. In that case, EF would not know the current schema to compare to the new, so it would just assume you know what you are doing and it would not touch the database schema.
Code first does not have the ability to upgrade your database while keeping your data intact.