I'm writing a rails app that is not intended to act as a web server; I only want to use it to manipulate the database easily. The same application can be used to manipulate many databases on one machine.
This situation is quite similar to git; one git app, one machine, and several git repositories.
I am using sqlite3.
Rails has only one config/database.yml per app. I'm looking for a way to switch between config/database.yml's for each of my app's repositories. In git, you switch repositories by changing the current directory. For my app, any alternative to achieve this 'swapping' of config/database.yml is OK for now.
Related
I'm embarking with 50 related rails apps that will have minor differences between them - the css may differ and maybe each app will have different routes and different titles for the views for the sake of SEO and so on.
But i want all 50 apps to be consistent when i change other things. So basically i will have to end up with my own cms and each website will have different settings.
I'm sure i'm not the first person to encounter this problem. How would i go about organizing this while using Rails, git, github and heroku so that when i deploy, all apps update and remain consistent but still hold their own settings?
I fork a base project and keep it as "upstream".
I clone the forked project in my development environment and keep it as "origin".
So my development environment has an origin and an upstream.
When I do something that effects all forked projects, I do the change in upstream, then I go into each project, pull from upstream and merge.
You can also have a hierarchy of upstreams and keep them synchronized with the original upstream.
If those are purely configuration files, the best approach is to follow the Heroku page "Configuration and Config Vars":
Don't put those files in a Git repo itself.
Use the Heroku CLI’s config, config:add, config:get and config:remove to manage your config vars
I'm a huge fan of only having to maintain one project if it's possible. If it's only the (user-controlled) styling of an app you might go with a multi-tenant approach in the basecamp style. Your app would display different endpoints, e.g. differentiated by subdomains, that you could also point different top-level domains to. The variable parts of the app then needs to be stored in the database, such as e.g. the styles, layouts, and whatever user-controlled content you have. One approach is outlined in the answers to this question, though there are definitely more ways.
My brother and I are collaborating on an app from two different computers -- one mac and one pc. I can't for the life of me get Postgres to work on his computer, and after a whole bunch of hours, I decided to just have his computer run sqlite3 for development (which is easy as pie), and basically have all the production stuff happen on my mac, while still allowing him to make functional changes from his pc. And merge them to github.
The trouble is, this involves having two different database.yml files, two different db/schema.rb files (I think), and different gemfiles, one with sqlite and the other with pg.
My thought was just to do all that on his computer and add those files to the gitignore file. But if THAT isn't ignored, then when I pull back to my mac, won't I be merging his incorrect configurations to my machine?
At any rate, that's why I was thinking of adding .gitignore to .gitignore. Will this work? Will it create universe-bending paradoxes? Is there a better way to do this that I don't know about?
Are those two schemas really different? They usually aren't.
If they aren't then just ignore config/database.yml and create contig/database_sqlite_example.yml and contig/database_ppostgresql_example.yml. That way, when someone clones repo, he can use SQLite or PostgreSQL by simply copying example file to database.yml (which will be ignored)
No, don't ignore .gitignore
I've always liked the idea of creating local branches for this. I actually go a little local branch crazy... but that's a different issue all together.
If you want to have a private little work bubble then keep your branch local only. You control what gets merged into master (or whatever your development branch is) and you can commit everything in your local branch to git for history sake.
If you want to share what you are working on then just share your branch out. But this way you can keep your environment setups isolated while sharing the local branch so that it is visible for collaboration.
There's plenty of good documentation on Git Branching and Sharing so I'll leave that to you instead of clouding the post with links that surely will get broken.
I'm not sure any of us "really want to" be working directly in the master anyway, especially in collaboration efforts such as yours.
So I am starting to learn rails, with a php and front end background. I created a new rails project and that was going well enough, until I downloaded another rails app off github and installed all dependencies and gems...anyway these problems have been my undoing for the last two days...I would really appreciate some clarification.
How exactly do you manage local databases for a development version as opposed to those external databases for a live version?
Will Rails build a local database automatically after an application is imported from Github for instance? Or does one have to be created manually, also should it have the same authentication credentials that the downloaded uses to talk to its database?
Also, after I downloaded PostgreSQL and its gem, I can no longer start rails server for my old rails project, or for my new one for that matter, both get these errors:
gems/actionpack-3.0.16/lib/action_dispatch/http/mime_type.rb:98: warning: already initialized constant PDF
gems/activerecord-3.0.16/lib/active_record/connection_adapters/postgresql_adapter.rb:950:in `initialize': FATAL: role "postgres" does not exist (PGError)
Since you're using postgresql (which possibly shared by several applications), and in my understanding, two rails applications usually do not share namespaces other than database, I guess you've not modified config/database.yml file.
By convention, the default development database name is development, so, if you haven't touch the configuration file, the two applications share same database options, cause conflicts.
I usually modify the database name to development_SomeApplicationName (replace SomeApplicationName with some meaning application name to differentiate database name) just after creating new application.
The company I'm working for currently has a Rails 3 application on a dedicated remote server. The current development environment is a local machine.
We are trying to put some infrastructure in place to hire some contractors to be able to do some development remotely. Obviously this won't work with our current development setup because it's local.
I was thinking that I could put the development and test code in separate subdomains i.e.
test.mydomain.com and dev.mydomain.com.
This is a small (but growing) project and we would not have more than one developer working on one or two changes on our system at any given time. We are starting out with smaller enhancements and working our way up to bigger ones.
My question is, what is the best way to deploy a development system that contractors would be able to access remotely and securely?
Normal practice would be for developers to still develop locally on their own systems, cloning the code using a version-control system (VCS) such as git. Then, you'd either 'pull' new code from a location they give you, or allow them to 'push' code to a location you give them. There might well be a 'staging' server set up, though, where the application is deployed as an additional check before deploying to the 'live' server; Rails lets you set up an arbitrary number of environments ('development', 'production', 'test' are the defaults, but more can be added), or you could use a deployment solution which ignores these settings and uses a different approach (such as Heroku).
You need to have source control, preferrably svn, then access that source code anywhere you want. Give a user id and password to the contractor and yourself to access the svn and install local development environment using local development database on your/contractor's pc. Anyone can deploy to dev. env. Or production env only if he/she has the authentication.
I am doing something similar. We use GITs to manage the code. To manage those different environments, I think using the GIT workflow is great, but the next step is configuring a remote database for development that all the developers access. They would just need to pull the code via git, once you are able to configure a remote database in the yaml., everyone would be in sync because you are developing on the same "dev" database.
Firstly, Happy New Year everyone.
I'm new to Rails, so please tolerate any incorrect use of terminology...
I have developed a simple Rails application, backed by a MySQL database.
I would now like to deploy this application to multiple, independent groups of users (i.e. it is a club application, and I would like to deploy it to a number of completely independent clubs).
I would like to use the same Rails Application code as much as possible, and just have a separate instance of the database for each club.
As each instance will be running on the same server (until server load proves to be an issue) I assume I can use a different port for each Rails server to steer users to the correct group?
I'd read that there are test and production modes, is it possible to have multiple [additional] instances of production modes, e.g. club1, club2, all sharing the same code, with unique databases?
My questions are how to support multiple separate database instances, and also how best to route to these?
Any advice on how to go about this much appreciated.
If you are using Git (I suggest you should be!) then you can keep a central version of your code in one place and then deploy it multiple times, changing only the database.yml file (it should not be checked in to your git repository in that case). http://git-scm.com/
Let's say you put all of your code up on github.com with username 'snips' and the project is called 'clubster'. Using something like Heroku you would then do:
git clone https://github.com/snips/clubster.git
cd clubster
heroku create boxingclub
Because Heroku auto-configures your database there is no need for a database.yml file
git push heroku master
And you'd have a version of your code deployed at boxingclub.heroku.com
When you make changes to your code you just go to each of your installations and do:
git pull origin master
git push heroku master
Which updates your code on that particular instance of your application.
And if you're getting a little more advanced you'd be looking at Chef to manage the whole setup for you. http://www.rubyinside.com/chef-tasty-server-configuraiton-2162.html
The other approach would be to have some kind of subdomain system, but I'll leave that to others to cover.