I have a database that I created and populated using the development environment in Rails 3.2. I deployed the database onto a server using git and phusion passenger. Currently the server is still running the development database because it is the one that is populated. I have 2 questions:
1) If I switch the server to the production environment, will all of my data transfer over? If not, how to I transfer the current data into the production database?
2) If I push updates to the server from my personal machine using the development database, and the server is using the production database, will all of the data that has been inputted into the production database by users stay in tact? or do I have to configure it to not erase data when I pull my project to the server from git?
For the first question:
If you change the environment to production, it will use the database which is configured in config/database.yml file. You can take a backup of the development database and import the backup file if you want to use the same database in production.
For the second question:
By the term push updates to the server from my personal machine, i assume you are talking about code changes being pushed and not any db related things. pull/push operations with git will never affect the way you interact with database. The data from users in production db will remain intact.
1) If I switch the server to the production environment, will all of my data transfer over? If not, how to I transfer the current data into the production database?
It will not generally by default. The database.yml file has a group for development, testing, and production. Development and Testing will tend to be local, and production (hopefully) is not going to be on your local machine.
2) If I push updates to the server from my personal machine using the development database, and the server is using the production database, will all of the data that has been inputted into the production database by users stay in tact? or do I have to configure it to not erase data when I pull my project to the server from git?
The actual data should stay in tact, however, remember to make your migrations compatible with the data that is up there. One big thing to watch out for here is adding a mandatory field to an existing table without dealing with repopulating earlier records. This will break your deployment.
You can get the database from production/send it back by using your environment's resources (I think Heroku uses pg:dump).
WRT your comment on GhostRider's answer, are you using the production DB remotely from development?/Where is your deployment? What does your database.yml file look like? (remember to not include your passwords :D, I will update answer on reply).
Related
I am using electronjs and pouchdb to sync data to a remote couchdb. I have a remote dev couchdb that I use for testing purposes and a remote production couchdb.
when I run electron . the application syncs the data from the remote db and stores documents locally electron's pouchdb and vice versa.
Things are fine but when I change the remote database URL from dev to prod, the locally stored dev data gets synced to the production couchdb.
Is there any way (programmatically) to stop this from happening?
You can not just change the URL of the remote database from Dev to Production.
Pouchdb does not know that this are two different databases and therefor starts syncing. If you want a Dev and a Production Database you need to create two local databases. One that is synced with Dev and a separate one that is synced with Production.
The strength of CouchDB is that it can sync with any other Couch.
If you are required to have two-way replication aka sync then you might consider filtered replication[1].
However if you only need to replicate remote documents to the local database, then simply use one-way replication[2], for example
PouchDB.replicate('http://<remote host>/mydb', 'mydb');
1 PouchDB Filtered Replication
2 PouchDB Replication
I have a live, functioning Rails app that is currently running on Heroku. In order to scale back on costs, I'm in the process of migrating the whole app to Digital Ocean. Much of what I've done so far has only involved adding extra gems and files to support Capistrano deployment, but I just ran into the first (presumably of many) instance where I need a different configuration for my app on Digital Ocean vs. what I use for Heroku. Specifically it's Redis. On Heroku you need to use an add-on ("Redis To Go") since you can't install Redis directly. Thus my reds_init.rb looks like this:
if Rails.env.development? || Rails.env.test?
redis_conf_path = Rails.root.join("config/redis", "#{Rails.env}.conf")
redis_conf = File.read(redis_conf_path)
port = /port.(\d+)/.match(redis_conf)[1]
`redis-server #{redis_conf_path}`
REDIS = Redis.new(:port => port)
end
if Rails.env.production?
uri = URI.parse(ENV["REDISTOGO_URL"])
REDIS = Redis.new(:url => ENV['REDISTOGO_URL'])
end
That production configuration is Heroku-specific and for Digital Ocean I'll be needing something a lot more like (perhaps exactly like) the test/development configuration. However, during the migration I need to have both working as I may need to deploy code (bug fixes etc) to the live production environment while slowly setting up the Digital Ocean environment.
Since there will likely be many other instances of this sort of thing as I work through this migration, I'm thinking that the best way to handle this would be a separate Git branch for the Digital Ocean environment. But I'm not entirely sure the best way to set this up. I'd really appreciate any pointers from someone who's had to do a migration like this on a live site.
Here are my thoughts with a general outline of the approach I've taken in the past:
For good measure, make sure your production environment is stable (tests passing) and preferably deployed off of the master branch on git. You'll want to be able to reliably deploy hotfixes on master as well as cross-reference any future changes during your migration with your development environment. Backup your DB as well.
Create and checkout a new git branch for digital ocean.
Create a new Rails configuration environment or digital ocean preferably with a name consistent with your branch name in (2). Make sure your new environment is isolated from what you're using in production. In other words, you shouldn't be able to "contaminate" your production environment from your new environment. This means all db & api connections use separate credentials. Also try to keep version control in mind with commits tracking specific changes. This will make debugging easier through git bisect if necessary.
Configure and test deployment of your application server on digital ocean using data in a seed database. Make sure you can perform all aspects of deployment, including running migrations, asset precompiling, bundler, stability of nginx/unicorn without affecting the stability of the site.
Take snapshots of your production database(s) on Heroku and import them into the database you're using on Digital Ocean. Again test your site and make sure it's working properly with production data.
Schedule a time when you can take your site offline for enough time to do the migration. You'll need to move DNS, DB data, environment configurations, and whatever other environment specific data.
Since your master branch should be stable, you can always go back to it to deploy bugfixes as necessary. However, make sure you incorporate (git cherry-pick) these commits into whatever branches are ahead of master for consistency. I'd recommend checkout out git-flow if you haven't already: http://nvie.com/posts/a-successful-git-branching-model/.
This is mostly just food for thought as there's a lot to be said about the subject of migrating an application between data center. Specific approaches and strategies are going to depend on your dev ops setup and application environment.
I've got a Rails 4 app, hosted on Heroku. I'm running it in production already, and want to be able to make improvements to the app periodically, without touching the production database.
(There's user-generated data in the live app already, and my improvements are to the logic and design, not the database).
Am I correct in thinking that if I re-deploy the app with git push heroku master after each modification then the data in the production db will remain intact?
Thanks.
Yes, redeployment will not alter your database.
Only the app code changes. The database is completely different and thus remains intact.
I'm very new to Rails.
I am confused about the development and production databases. I am using postgreSQL for all of my environments and heroku to host the site. I am able to push migrations and seeds to my production database on heroku. However I entered quite a bit of new data through the browser on localhost:3000. I spent a long time trying to figure out how to get that data to heroku but finally was successful by destroying then creating a new empty database and pushing my development database to it. Now my site on heroku is the same as localhost:3000 using rails server. I modified the database.yaml file so that the development and production databases are now the same name (the name of the development database). But I don't think that means that if I make changes to the development database through localhost:3000 they will automatically be changed on the heroku site. I am very confused about the colors (CRIMSON, MAROON) on heroku - are those different databases than what I specify in the yaml? And I don't know whether I should now be entering new data on the localhost:3000 site or the heroku site. Sorry if this is very amateur. Thank you.
You're getting confused with how Rails uses Databases
Let me explain:
Rails uses the MVC (Model View Controller) programming pattern to populate your applications with database data. Rails uses this pattern because it's the most efficient & extensible, and it works by taking a command from a user (clicks a link, inputs data), sends to the controller & performs the request on the model
The way all rails applications work is to take commands (which you define), and perform database operations with them & then repopulates the app with the new data
Rails is designed to work with a single database, and the database.yml file is there to specify which database that is (it's good practice to have different databases for development, staging & production -- for performance, efficiency & other issues)
This means that the database name is not important - what is important is to keep both databases up to date using the rake db:migrate system to give all databases the required columns to make your app work properly
In answer to your question, the data you have is going to be different for development & production. Your production environment is meant to be that "holy-of-holies" where everything is compiled & running efficiently
The production environment is meant to handle its own data, and should be populated through your application. The reason for development & production databases is to ensure you can "get things wrong" in the development environment before you try and apply it to the production db
If you tell us some more about your specific issues, we'll be able to give a much more refined answer
I'm currently developing my Rails app on my local machine. I have no DB installed on my local machine, and I'm sending my codes to remote testing server which actually runs the app in development mode.
Until yesterday all commands like rails g model foo or rails g controller foo on my local machine worked with no errors.
But now all of rails generate commands started to fail due to no database connections. I think the direct reason is because I made some changes to my app configs, but I'm not sure where the changes are.
I guess the wrong part is that rails generate commands are always invoking active_record
which always verifies the DB connection.
Now, my question is:
Is there any way to temporally disable rails to verify the database connections, for local development(which has no DB connection available)?
I tried removing config/database.yml but it didn't help.
Your local development environment needs to have the same sort of facilities as the application requires. If you have database backed models then you need a database, preferably the same one as used when deploying the application so your tests are useful.
It really shouldn't be a big deal to set up a database for local development. Depending on your platform there are usually many different easy to use installers available.
Uploading your code changes to a remote server for execution is a really dysfunctional development model. If you have no alternative, it might be best to create the models on the remote system and pull them down to edit.