I have a project on heroku working fine. Now I want to create same project with different url (same code) as the one I have working now. So that I can give the new url to the customer as a 'test' site. I know in heroku i can just rename the url but I want to completely separate development from test (database wise).
What is the best solution? Do I start from scratch? cd into new folder on my machine...clone project from github...make new database -test ...push to heroku...etc. etc.
Heroku toolbelt now provides a fork method to clone an existing application. It will duplicate your app with same source code, same database data and same add-ons.
Just type :
heroku fork --from sourceapp --to targetapp
https://devcenter.heroku.com/articles/fork-app
You should check out heroku_san, I designed it specifically for deploying multiple environments to Heroku easily. It also has grown to include a lot of other niceties you'll need to automate when dealing with multiple "apps" like sharing and auto migrating with restarts.
Once you have it setup it's as simple as:
rake production deploy
I'm using a method very similar to the one presented here:
http://jqr.github.com/2009/04/25/deploying-multiple-environments-on-heroku.html
What is the best solution? Do I start from scratch? cd into new folder on my machine...clone project from github...make new database -test ...push to heroku...etc. etc.
Yeah, I'd just make a copy (clone) of the repo, either from GitHub (if you have it up on GitHub) or the current Heroku location. Then start a new project in Heroku and push the cloned (and possibly modified) second site up to Heroku as that project.
Related
I have deployed an application in Heroku. It is Rails applications. The DB is postgres. So this is the app in heroku. Now I want to create new app which will be a clone of the previous app. But it will have separate DB. How should I get going? I would also like to know about configuring the DB from heroku. I am not so techy so please go easy on me.
Thanks!
But it will have separate DB
So, just create a new heroku app, add PG add-on to it, and that's it. No more steps. It will have a separate database. I think you don't even have to add PG add-on, it probably is added by default.
If you wanted two apps use the same DB, then you'd have to do extra steps.
You can use Heroku Fork to clone your application. This will copy the app, environment variables and any postgres databases (and their data if you want it) to a separate Heroku application.
heroku fork --from old-app-name --to new-app-name
Is there anything I want to gitignore in my rails neo4j installation if pushing to a public repo? I am a newbie at neo4j and I noticed some development private keys under db/neo4j/development/certificates. Obviously I would't want to push up my production private key, but will it be ok to push up my development and test keys? In general, should I be pushing up the db/neo4j/development/ and db/neo4j/test/ folders or should I expect newcomers to a project to run rake neo4j:install[edition,environment]
After a little research I found that this one neo4j rails example does in fact ignore the whole installation:
https://github.com/andreasronge/neo4j-rails-example/blob/master/.gitignore
but it seems like I would not want to ignore the migrations.
Is there an issue with developing my site on my macbook and then moving to a server when done? Will there be issues I need to plan ahead for? DB or ruby related maybe? Dependencies or something a server could have different from my dev environment that could cause a nightmare later? I'd rather develop it offline since it'd be faster and wouldn't require an internet connection but in the past I've always done everything with live sites so this would be a first, and I am new to ruby on rails.
Developing locally and then deploying to your server(s) via something like capistrano is standard practise.
It's a good idea to keep your development environment as close as possible to your production environment (ruby versions, database versions etc). Bundler makes keeping your gems in sync easy
I used Heroku for some projects. The deployment was as easy as it could be. I just did a git push and it worked without problems... I really like bundler and rake :-)
Your Question embodies THE way to develop in Rails. Your development environment is an offline representation of what you're production site will be.
A quick workflow analysis for you could be:
rails new ~/my_app -d postgresql; cd ~/my_app; rm public/index.html
Next, create the database:
bundle exec rake db:create:all
Now you'll have the db and app all set up, let's set up your main pages:
bundle exec rails generate controller Site index about_us contact_us
Now you'll have something to see on the site, so run:
bundle exec rails server
This server acts as your offline connection and will handle the rendering of any text, images, html etc you want to serve in your rails app. Now you can join in the debates of TDD, to TATFT or JITT, rspec vs test::unit. Welcome.
Developing locally is definitely the way to go. However, I would look into getting it on production as soon as possible and pushing often. This way you can see changes happen as you make them and are aware of any possible breaking changes.
I use heroku a lot and when I start a new project I push it to heroku almost immediately. While developing, I can publish new changes simply by git push heroku master. Everyone has to find their own workflow, but this has always worked well for me.
If you are interested in Heroku here is a good link to get you started:
https://devcenter.heroku.com/articles/rails3
I have a Rails project under git.
The structure is:
SomeProject
-Docs
-Src
-Rails
Rails is the root of the rails application, but SomeProject is the root of the repo.
When I try and push to Heroku I get:
Heroku push rejected, no Cedar-supported app detected
So my questions are:
Would this be resulting because the rooot of the repo and the root of the Rails application are different?
If so is there a way I can tell Heroku where the root of the Rails application is?
If not what else would cause this problem?
This is not an ideal situation, especially for heroku, but the generally accepted solution is pretty straightforward. It will take a bit of work on your behalf, but nothing too bad.
Create two repositories, one for the rails app, and one for "SomeProject."
Add your rails app as a submodule to "SomeProject." You can add them pretty easily, using something like git submodule add git#github.com:user/rails_app/ rails. This will add the rails application as a submodule to your project, so it's essentially it's own repository. Find more information here.
Add heroku as a remote to the submodule, and when you want to deploy the app, push from the submodule, rather than the entire project.
This is not as easy as git push heroku master:'/rails', but nothing like that exists (yet, anyway).
Hope this helps!
The easiest solution is to split out your Rails application into its own repository, as andrewpthorp suggests.
Another solution is to write your own buildpack in a separate repository, based on heroku/heroku-buildpack-ruby but customized to support your alternate project layout, and use that to deploy your application.
This could be a noob problem but I couldn't find a solution so far.
I'm developing a Rails app locally that uses SQLite, I've set up a local Git repo, and the dotcloud push command is using this. Locally I use the dev environment and on DotCloud it automatically uses the prod env, which is great. The problem is that each time I do a push my prod db on DotCloud gets lost, no matter how minor the changes are to the codebase, and I have to run 'rake db:migrate' to set it up again. I don't have a prod db locally, only the dev and test dbs.
Put your DB in ~/data/ as described here and create a symbolic link at deploy time:
ln -s ~/data/production.sqlite3 ~/current/db/production.sqlite3
You should not have your SQLite database file in version control. If you had multiple developers it would conflict every single time somebody merges the latest changes. And as you've noticed, it will also be pushed up to production.
You should add the db file to .gitignore. If it's already in version control, you'll probably have to git rm the file first.
The problem is that every time you deploy, the old version of your deployed app is wiped, and replaced with the new code, and your sqlite db is usually within your app files. I'm not a dotcloud user I don't know it it works, but you can try to setup a shared folder, where you put the production database on the server, which is outside of your rails app.
Not really sure how git is setup on DotCloud.com, but I'm assuming there is a bare repo that you push to and another repo that pull from the bare when a suitable git hook has been executed. You need to find out if you can configure that last pull to use the ours merge strategy.