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.
Related
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.
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.
Especially when considering a fresh Rails project, what does your version control and deployment workflow look like? What tools do you use?
I'm interested in answers for Mac, *nix and Windows work machines. Assume a *nix server.
I'll edit for clarity if need be.
Create a copy of my personal Rails 2.1.1 template with preinstalled plugins and frozen gems.
Change DB passwords, session secret/name and deploy.rb.
Create a private or public repository on GitHub as needed.
Push the empty rails project to GitHub.
SSH to Server and configure apache (copy Virtual Host file and mongrel config files from old project)
Create empty database on MySQL server
cap deploy:setup && cap deploy:cold
If everything works so far: Start developing and committing to GitHub. cap deploy as needed.
Update: Don't forget to write tests for everything you do!
Using Windows Vista and a fresh Ubuntu install at Slicehost.
Create a new empty project in
NetBeans.
Fire deprec (http://www.deprec.org) to install
the Rails stack, including version
control, on the target slice.
Commit the empty project to Subversion.
Using Capistrano, test deploy.
Begin actual development after I've verified that I can access the
Rails start page and, possibly,
scaffolding. (This is really not
necessary because I've done this several times and the software works like it says it does.)
Deprec is seriously magic -- it takes the time it takes to clean-start a Rails project (including server configuration and all that jazz) from about a working day down to about an hour -- and that is an hour where you can be doing coding while everything installs.
this guy documents every workflow he's ever experienced
http://subtlegradient.com/articles/2007/03/30/web-development-environment-and-workflow