Ok, let's say
I changed Prisma schema and ran yarn prisma migrate dev and created a migration.
I noticed there was a typo in schema, so I fixed it
I forgot to run yarn prisma migrate dev again after fixing a typo, so no migration was created for this change.
And this mistake went to a pull request. And it will be merged if nobody notice this mistake.
And this point, how can CI detects there is a schema change but no migration for that?
Thanks.
I just decided to use Circle CI's no_output_timeout: 1m option on run. and just run yarn prisma migrate dev with postgres docker image on CI.
So, if there is no unsynced stuff between schema and migration, it will pass.
If not, the promft will wait for user's input to get new migration name, so Circle CI's timeout kicks in here and it will make it fail. So we're able to know there was a mistake.
It works pretty well.
Related
Basically what I have is my frontend (Vue) and my backend (Node.js and etc.). By following a guide, I've built the frontend for production using npm run build. I got a bunch of files in a build folder I setup within a previous step. These files were then moved to a folder in the backend. It works, but it's more a demo than anything else, and the frontend and backend will have to be modified more as I continue.
I'm just wondering if and when I edit the fronted more (let's say, when I add a new page) am I supposed to go through this process again? So I'll modify the front end folder, build that, move files, etc.
Thanks.
Yes, definitely.
If we are in a development environment, we use npm run dev or yarn run which upholds the development environment running and updates the browser whenever any modifications inside the code happen. We don't use any final build in the development environment because we make code modifications so repeatedly that it would be a sore process to make a build after every modification and check the results using that build.
But, the production is distinct from the development environment. We deploy the only code which is bug-free, entirely working, and ready for users to use. Deploying to production means all changes have been made, and the final code is ready to be deployed. So, we make a final production build and deploy it to our server.
So, don't panic to deploy to production every time you make a small change in the code. First, complete your all changes, and test the changes in the development environment, if everything is working correctly then only create a final production build, and deploy it to the server.**
I hope this helps.
I am try to upgrade exisiting ember project cli version by following this tutorial
https://emberigniter.com/update-latest-ember-data-cli/
after finishing this i try to run ember serve it shows error like
missing path
i doknow what exactly it was trying to say and also i am new to ember could any one help me sort out this issue.
I recommend using ember-cli-update to update your ember projects. Please check it out. It avoids user-mistakes while upgrading (no manual merges, etc. ...).
You could try to delete node_modules and run npm install again. It could a package in your package.json that ember serve can't find. Also check the releases it is not easy to upgrade from older version to the latest one, too many deprecations. Also if it si too old i suggest you to start over create again the ember app.
I am trying to use Sequelize js with Serverless, coming from traditional server background, I am confused where/how to run database migrations.
Should I create a dedicated function for running migration or is there any other way of running migrations?
I found myself with this same question some days ago while structuring a serverless project, so I've decided to develop a simple serverless plugin to manage sequelize migrations through CLI.
With the plugin you can:
Create a migration file
List pending and executed migrations
Apply pending migrations
Revert applied migrations
Reset all applied migrations
I know this question was posted about two years ago but, for those who keep coming here looking for answers, the plugin can be helpful.
The code and the instructions to use it are on the plugin repository on github and plugin page on npm.
To install the plugin directly on your project via npm, you can run:
npm install --save serverless-sequelize-migrations
Lambda functions were designed to be available to run whenever necessary. You deploy them when you expect multiple executions.
Why would you create a Lambda function for a migration task? Applying a database migration is a maintenance task that you should execute just one time per migration ID. If you don't want to execute the same SQL script multiple times, I think that you should avoid creating a Lambda function for that purpose.
In this case, I would use a command line tool to connect with this database and execute the appropriate task. You could also run a Node.js script for this, but creating a Lambda to execute the script and later removing this Lambda sounds strange and should be used only if you don't have direct access to this database.
I got an application written in YII that from time to time will need version update. Currently, when we release a new update, we manually run a shell script to copy/overwrite the application code/source files from our git repo and set the appropriate permissions and other things, then at the end of the script, we run a YII command to run our database update. We have versioning on our database update. We also rollback changes to the database if one of the sql statements of a version fails. Now the issue occurs if a database update fails, and the application code/source is updated, then it will fail when it tries to access some table fields, table or views.
How to best handle an application update with versioning? Much like the way wordpress handles its update or better.
Would like to ask for suggestions to the rigth approach, it may include RPM, GIT or other info.
It would be good to have a detailed list of processes from you guys.
Thanks.
Database updates may include backups, and running multiple scripts, and
should be handled outside of rpm packaging. There are too many failure modes
for RPM scripting to handle flawlessly.
You can always package up the database schema update script in the package
and then check for the correct schema version when your application starts,
providing instructions (or a pointer to instructions) on how to upgrade the
database, and how to reinstall the last-known-good application, when the wrong
schema version is detected.
how can I disable completly the migrations of EntityFramework? I mean, what are the best practies when you are almost ready to go live with your web app? I'm worried that some automatic script reset my DB :)
Many thanks,
davide
Migrations are normally used on the development database. For production I would suggest that you instead export an SQL script using the Update-Database -Script command which can then be run on your live database when you need to update it. It would be dangerous to have your development application pointing to a live DB and to run migrations directly.