I have my Strapi deployed, and users are able to log in to their account and add new entries to the server. The server will then store the content in PostGres on Google Cloud Service. However, I want to be able to reflect the newly added entries for my local server as well, since I need to manually add some image assets for each entry. Is there a way for me to somehow retrieve the new entries from database and directly add it to my local Strapi admin dashboard?
You can use same database for local dev and production versions. In that way the content of production version is the same as dev version.
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
Anytime my app goes to sleep and comes back on, I lose data in my database
And I'm not storing any media, it's just form data (texts)... I built the app on strapi and I've followed all their guidelines but it keeps happening. I'd be happy if anyone can help
Local data (files, db) is cleared after a Dyno restart because the Heroku File System is ephemeral. A Dyno is restarted (at least) every 24hrs.
In your case Strapi uses SQLite where data is saved in a local file.
Strapi suggests to configure Postgres on Heroku, alternatively you can use an external DB storage service.
First of all:
As you create content types with strapi it generates the code (= new files) for the according controllers/routes/services
Heroku does not persist data after a restart
After a restart strapi checks which content types exist in the code and deletes the tables of nonexisting types from the database.
Therefore, on Heroku you have to set up all your content types locally and connect to an external db (e.g. Heroku Postgres) but never strapi's default textfile based db.
Then push the generated files and finally deploy.
Thus, on Heroku you should always run in production mode. This way the option to alter content types is completely blocked and you will not run into the issue of data loss after a restart.
I have deployed Strapi headless CMS on Heroku free tier and tried to use it both with MongoDB and Postgres databases, whenever I restart the dyno e.g. during deployment - all the data created thus far is not persisted?
I tried rebuilding Strapi locally and I cannot reproduce the behaviour.
I am using free tier for hosting of Strapi as well as free tier of Heroku Postgres.
Most likely you created your project with --quickstart which is not Postgres, it is SQLite. Can you please check your config/environments/*/database.json files and ensure you have PostgreSQL setup?
All model configs are stored in files meaning you will not be able to create, edit, or delete new models, fields, components while using Heroku. All data (content) is saved to the database.
https://strapi.io/documentation/3.0.0-beta.x/guides/deployment.html#heroku
I want to understand how people are handing an update to a production app on the Parse.com platform. Here is the scenario that I am not sure about.
Create an called myApp_DEV. The app contains a database as well as associated cloud code.
Once testing is complete and ready for go-live I will clone this app into myApp_PRD (Production version). Cloning it will copy all the database as well as the cloud code.
So far so good.
Now 3 months down the line I want have added some functionality which includes adding some cloud code functions as well as adding some new columns to the tables in the db.
How do I update myApp_PRD with these new database structure. If i try to clone it from my DEV app it tells me the app all ready exists.
If I clone a new app (say myApp_PRD2) from DEV then all the data will be lost since the customer is all ready live.
Any ideas on how to handle this scenario?
Cloud code supports deploying to production and development environments.
You'll first need to link your production app to your existing cloud code. this can be done in the command line:
parse add production
When you're ready to release, it's a simple matter of:
parse deploy production
See the Parse Documentation for all the details.
As for the schema changes, I guess we just have to manually add all the new columns.
I am new windows azure user. I have gotten selected for 90 days trial account and I am able to upload my ASP.NET MVC3 application to my account. My site is also running now. After I did publish my site, I added more model, views and controller to my proramme. Now I can not find a way to update my application. I can again publish my application but update option is not there. I want to update my new code only but the package option is creating full application. How I can update the new code to my site in windows azure cloud?
[Changed spelling]
With Windows Azure you can publish/update an application following ways:
Log into you Windows Azure account. Select you hosted server name and at the top panel you will see "Upgrade" option, when you will use this option you will be given a chance to select your CSPKG and CSCFG file from local file system or from Windows Azure storage. Once you selected new or updated CSPKG, your current running service will bee upgraded.
You can also use Windows Azure PowerShell Cmdlets to upgrade your current running hosted service using "Update-Deployment" command:
2.1 http://wappowershell.codeplex.com/
You can other 3rd party applications created using Windows Azure Service Management API to upgrade/manage your current running hosted service.
3.1 http://wapmmc.codeplex.com/
3.2 http://www.cerebrata.com/Products/CloudStorageStudio/Default.aspx
Note: With Visual Studio if you again publish your application, it will delete the current running hosted service and then create the new on so for update it is not the good one.
Finally based on your question about partial update, that is not supported. Even when you make a single line change in your code the deployment will be considered a full deployment even when the action is "update/upgrade". There is no diff package deployment so evertime you update your Windows Azure application, you will use the newly created CSPKG file and upgrade your hosted application.
Regarding partial update: If you have multiple Roles, you may choose to upgrade a single role (so that would be a partial update of the deployment). For a given Role, all code is redeployed. If you're running more than one instance, the update will be rolled out across groups of instances, not all instances at once.
For updates such as static content: if you move these into blob storage (a great place for css, jquery, images, etc.), then you may update this content by simply uploading new items to blob storage individually. These updates don't require any code to be rebuilt or redeployed.
If you're in dev mode (e.g. non-production), you may enable Web Deploy, which then allows very fast updates of your app to the running instance. This only works in single-instance mode, and it's great when doing frequent code+test cycles.