I'm new to rails, and I accidentally ran rails db:rollback command in a development.
Next I did rails db:migrate:up VERSION=XXXX to change status of the file I rolled back from down to up.
The migration file was about images. However my images were gone in a development mode due to rollback, files status the same as before I ran rails db:rollback.
In this case, if I pushed this to remote repository, and it's merged in production, the images already there will be gone as well as mine in development?
When add_column method in migration is run you just add column in migration so it will run for production & development environment. Now you added images through localhost to your application and stored in database. So those will be stored to database regardless migration.
Rollback will remove column running remove_column so it will hamper your development as removing column will make you loose all data inside column of table. So on production it does not deal same.
Images are getting pushed to production database or remote repository, it is just to add or remove column only so rollback will affect only your local/development
Unless you're doing something wacky in your migrations, any goofs like this you make to your development database will not effect production. That's why dev and prod databases are separate.
The general problem of "is it safe to push to production" can be mitigated by adding a staging server which runs in the production Rails environment, but is used for additional manual testing of new features. Once everything checks out in staging then push to production. Many services provide a "pipeline" to do this for you, for example Heroku Pipelines.
Related
I have some sort of snafu that happened where an intern accidentally uploaded a bit of code to our staging site and then cancelled. Now, there is a page on the staging site that requires a migration that doesn't exist on the staging site.
I'm relatively new to this as well and I'm wondering what the best way to add a migration for that missing column directly to the staging site. Is it
Pull the code, add the migration, push the code (which changes the
staging from the dev, as the dev has the master.
Generate the migration in some other way in heroku directly?
I honestly don't even know if the way we think this error happened is actually the truth. I just have to fix it.
If your migration existed you can rollback on directly on heroku in activity onglet.
or
Pull your repo
Add your migration
Push it on heroku
Run heroku run rake db:migrate --app your_staging_app
Recently I had an issue where my db scheme change wasn't being reflected on Heroku PG. I double checked to see that both migration and seed succeeded. What was even weirder was that the db scheme change worked fine on a staging heroku deployment (after the exact same migration/seed). After some searching around, I learned that you are supposed to restart heroku after migrations via:
heroku restart --app=app_name
I've never had to do this (I'm not exactly a veteran, but I've run a good amount of migrations before and have never had to restart heroku for this particular reason).
Do I actually need to be restarting heroku after each migration? Or is this more of a case by case thing?
If you make changes to your DB via migrations then you will need to restart the application on Heroku. When Rails starts in production mode it caches the DB schema. Migrations run in one off processes which the running web process is not aware of. So for it to pick up the changes you need to restart at least your web processes. If your application was idling when you deployed and you ran the migrations it would pick up the new schema as the app started.
You need to get your app to pick up the new migration. Restarting the app works just fine. Or you can clear the schema cache:
heroku run rake db:schema:cache:clear --app=app_name
It depends i guess. Speaking generally, the answer is NO. If you restart your app locally after every migration, then it is needed else i don't think it is required .
I'm missing something here.
I just fixed a bug on the production state of my app. When I merge it to my development state, it works very well (locally and remotely).
But I really don't know how to get my local machine to my production state, since the db state has changed since then.
Which means I'm about to push to staging a modif I haven't even tested locally.
What's the best practice in this situation?
To have multiple local db states by creating more local environments?
To rollback my db to the previous state? (How?)
To reset my local environment accordingly?
To "save" the db state when push to staging/prod to be able to restore when in this situation?
Anything else?
Feels like this should be routine for every app manager, but I really can't see how to deal with this, and find rails migrations not so handy at the moment...
Thanks
To get your local database to the same structure as what you have in production:
First get a local checkout of the branch or tag that's deployed to production.
rake db:test:prepare
rake test # or rake spec
That should clean out your test database, and then recreate it according to your db/schema.rb, which should be the same schema you have in prod. Assuming that you first wrote a failing test, then fixed the bug and watched the test pass, your tests should now be passing.
I'm considering paying the $50/ mo for a production database so I can use PostGIS with my rails 4 app. My issue is that I would like to continue developing with a 'staging' environment, but can't yet justify paying for two production databases. Staging is obviously just a clone of production, so just pointing both apps to the same DB url (post) would likely cause some major headaches.
Is there any way to partition the database, or another strategy you'd recommend?
Initial answer from heroku support is no, but I'm hoping there's a scrappy workaround.
Thanks!
First off, I would highly suggest just paying the extra $50/mo. For that, you get all kinds of cool stuff like forking and pipelines, as well as the fact that this is kind of hacky. I honestly don't know if this might end up wiping your production data when you clear the staging database. Please make backups before trying this.
I'll view this answer as an answer to a technical challenge rather than a business decision. Without further ado,
Setting up multiple environments on the same database with Heroku Postgres schemas
First, I deleted the existing dev database and added a production database to my production app.
heroku addons:add heroku-postgresql:crane
> Adding heroku-postgresql:crane on test-shared-app... done, v# ($50/mo)
> Attached as HEROKU_POSTGRESQL_RED_URL
This attached a database under the RED color, so replace HEROKU_POSTGRESQL_RED_URL with the appropriate color for your app.
This attaches a database to the production app, but we need to connect to the same app for staging. First, create the staging schema
heroku run "bundle exec rails runner 'ActiveRecord::Base.connection.execute(%q{CREATE SCHEMA staging})'"
Next, create the staging app. See Managing Multiple Environments for an App for more information.
heroku create --remote staging test-shared-app-staging
heroku config:set RACK_ENV=staging RAILS_ENV=staging --remote staging
Then, copy the environment data from your existing app. Add ?schema_search_path=staging to the end of the URL.
heroku config --remote heroku --shell
# make note of your database URLs
heroku config:set --remote staging \
DATABASE_URL=postgres://...?schema_search_path=staging \
HEROKU_POSTGRESQL_RED_URL=postgres://...?schema_search_path=staging
And push to staging
git push staging master
Now, run migrations on staging
heroku run --remote staging bundle exec rake db:migrate
And try it out.
My "app" is running at http://test-shared-app.herokuapp.com/posts and http://test-shared-app-staging.herokuapp.com/posts. You can see the source at https://github.com/benmanns/heroku-shared-app.
If I were you, I would use production DB until the right moment (start making money or getting more users, etc). I would replicate all the tables in production DB and give the new tables new names by prepending something like "stag_{original_table_name}. So, you would have two different sets of the same tables. In your models, make them use the new table on staging environment:
class Foo < ActiveRecord::Base
self.table_name = "staging_#{self.class.name}" if Rails.env.staging?
I am pretty cheap... and this may be an ugly solution in the eyes of the true Rails masters.
Heroku Schemas is another approach to this; it's a Heroku plugin that basically lets you run a single command to apply Benjamin Manns's solution of multiple schemas.
I've setup my app to run on Heroku with a staging and production environment as according to their documents. http://devcenter.heroku.com/articles/multiple-environments
It seems pretty straightforward to manage with the staging app, push entire deployments or new branches up to test in staging. What I wonder is how to manage the production version.
How do I keep my production up and running when deploying new code? Do I pull in the changes from staging or do I redeploy the entire app with the changes merged in?
Secondly, how do I manage and keep my database intact during all of this? I'm used to running locally where if you do a new deploy and a new rake :db:migrate, you lose all your database data. How is this done in production to not lose your records?
Thanks you and ANY other tips regarding heroku management is welcome.
Typically, you make changes locally, including migrations or whatever. Before pushing your changes to your production app, push changes to your staging app to double-check things are okay.
If you added migrations in your changes, be sure to run heroku run rake db:migrate to migrate your staging database. Running rake db:migrate should not destroy any data so long as your migration is proper - i.e. no weird tampering with data, just the standard addition/renaming/etc. of columns or introducing new tables. (Obviously if you drop a table in a migration it'll be gone.)
Then, if everything is okay with your staging app, push changes to your production, and again run heroku run rake db:migrate if you had any new migrations. If things are not okay, run heroku help to get a list of commands you can use - particularly ones with regard to releases so you can revert back to a previous release. Also heroku logs is really useful, and heroku console (actual command might be slightly different), though when you start a console, be really careful not to tamper with data too much.
With Heroku, there's no deploy command needed - right when you git push, your updated code is there. No "cap deploy" with capistrano, if you've used that before.
Hope this helps.