I have built a Rails application in a Linux environment but spent the last 2-3 weeks converting the application to work in a Windows environment for production (not my idea, I assure you).
I am using git and now have two branches of the same application, one that is configured to use jRuby on Windows with IIS8 and a MSSQL Server backend and the other which uses Ruby, a WEBrick app server and sqlite3 database for development/test.
I would like to continue using the linux environment for dev and test but will need to then combine my findings into my Windows branch.
I am hoping there is a way to create a branch using my linux environment, make changes to my app/ folder (which contains the brunt of the application) and then merge only those changes into my Windows branch. The issue here being if I merge normally, I will overwrite my files configured for Windows.
There are only a few main files I do NOT want merged with my Windows branch:
Gemfile
config/applciation.rb
config/initializers/assets.rb
config/database.yml
to name a few.
Does anyone have any idea how I might do this?
One approach would be to cherry-pick relevant commits. Another solution would be to have a core-repo and a repo for each plattform that you support and use git submodules to incoperate core.
But I agree with #mudasobwa, using configuration to switch implementation is much simpler and cleaner.
Related
I've been working on a rails project for a client that isn't technical. However, they want me to send over a deployment script, which their networks guys will use to deploy the application.
I've been using capistrano. But the problem is, cap is heavily dependent on the app itself. What i need is a script, that'd use the cap and config/deploy.rb but needs minimal setup on their local systems. The repo in the backbone is git based.
If this cant be achieved by capistrano, anyone knows of any other deployment utilities, that'd allow me stuff cap does and works independently? .. (i create symlinks and run some rake tasks in my :after_update block).
Thanks,
Hassan
If setting up a ruby environment to run cap deploy is not something that the "network guys" will be willing to do, then you're in for quite an uphill battle. Some suggestions to help alleviate this:
Have them use the railsready script to set up their environment
Give them a virtual machine (maybe a Vagrant box?) that can be used to deploy the instance
If you're doing a git-based deploy, you'll either have to set up a deployer key (and give this to them) or add them to your github project (assuming you're using github)
Consider bundling up the entire project and delivering as a tarball (or putting it into an rpm) and having them deploy this way (a quick&dirty way to do this is to deploy to a machine running the same distro as production, and tarring up the deployment directory)
Consider using a stack that more aligns with their network stack, like JRuby and warbler for deploying to Tomcat
Do some pair programming or at least screen sharing for the initial install. Sometimes the difference between loving and hating a platform comes down to the availability of help when problems arise.
Mina is like Capistrano but doesn't rely on being inside the rails application directory.
One option could be to setup something like Jenkins that will use capistrano to deploy. And your client can curl the jenkins build url to trigger a deploy.
Should my production Rails project use GIT? it will be easy for me to update the
servers and to push hot fixes, but what if I'll have a conflict during a pull?
and if I'll accidentally pull something wrong it make cause some downtime.
What is your advice on how to synch between the GIT repository & production?
Thanks
How about using a dedicated deployment system like Capistrano? It solves many of the issues you are trying to avoid.
Don't leave local changes on your production machines, and there is no risk of conflicts.
Production installs should pull from a dedicated branch/tag (e.g. use gitflow, production machines pull from the latest tag or simply master) - not the branch you regularly push to (develop, if you use git-flow).
I am developing 2 applications in Rails 3.1 (will upgrade soon), and have noticed that my current strategy has its drawbacks. What I am doing currently is:
Work directly on the development directory, have there version control with Git (which works perfect for me).
I have defined the databases like (omitted not interesting parts):
development:
database: db/dev.db
production:
database: db/dev.db
I have both applications running all the time in production mode, where the ports are defined as 3008 and 3009.
From time to time, I want to change little things, and start then a development server for one of the two applications directly with the defaults: rails s thin (port == 3000).
I have noticed that the following things don't work very well.
When I change CSS or Javascript files, I have often to cleanup (and after development rebuild) the assets.
Sometimes, the development server takes the files (CSS and Javascript) from one server and uses them for the other server. I have to manually clean the caches for the browser to avoid that.
What would be a better strategy to develop and use the two applications in parallel locally on my computer? Any tips and hints are welcome. Should I use a deployment tool (Capistrano) for that? Shall I roll my own Rake task for the divide? Or do I miss some magic switch that will heal the wounds (sounds pathetic :-))?
At the end, it is a mix of changes, so I answer my own questions and hope that others may learn something from it. At the end, there are 2 major decisions (and some minor ones):
Work with different repositories for development and production, even on the same machine. Add another one (a bare one) to synchronize the two. Push only from the development, pull only from production.
Use different ports all the time for different applications. Make a scheme like:
appA: dev ==> 4001, prod ==> 3001
appB: dev ==> 4002, prod ==> 3002
...
Here are the changes that I have done. rails/root is the root directory of my application, the overall directory structure is the following:
rails/
root/
another/
...
bare/
root.git/
another.git/
...
production/
root/
another/
...
Create 2 new repositories from the old one, one as a bare repository, the other one for production only:
mkdir rails/production
mkdir rails/bare
cd rails/bare
git clone ../root --bare
cd ../root
git remote add bare ../bare/root
cd rails/production
git clone ../bare/root
cd root
git remote add bare ../../bare/root
Don't use one (the same) database for development and production, just to be sure that Git can do its magic.
Develop (only) on the development repository.
After enough tests, do the following 2 steps:
root> git push bare
root/../production/root> git pull bare
Start the development server (only) with: root> rails s thin -p 4009
and the production server (only) with: root/../production/root> rails s thin -e production -p 3009
So as a result, I have a little more work to do, to stage changes from development to production, but I will eliminate those small irritations that were around all the time.
Running production servers on the development machine, or developing on the production machine is an unusual, even discouraged setup. Use your local machine to develop, run the server in development mode and run your test suite. Commit changes to git. Then, from time, to time, deploy to a server that runs in production mode. That's the recommended setup. As production server you could set up your own (e.g. your own machine or one in the cloud like EC2) and use Capistrano for deployment. More simply and with a lot less trouble, however, you can deploy to a service like Heroku. All you need to do is a git push and the app will deploy. A single instance of concurrency on Heroku is free, even.
Also, Windows is not a very well supported environment for running a Rails server, you're better off with Linux. For development, Windows may do the trick, but you'll definitely be in the minority. Most people are on Mac or Linux. Sometimes people recommend installing Ubuntu Linux on top of Windows in a virtual machine for Rails development.
I just began the process of setting up a new Mac as a Rails development machine, but the thought occurred to me: do I have to do all this again from scratch or can I somehow copy/clone my development environment from my existing machine (also a Mac).
Could I, for example, clone my machine using SuperDuper? Or are there any other tools to make the process of developing from more than one machine less agonizing than manually re-installing databases, Ruby, Rails, etc?
Thanks in advance for any ideas.
The rails framework itself is designed to be highly portable, especially version 3 ( with the introduction of a tool called bundler ), it lets you package all of your code and dependencies very easily which makes redeploying elsewhere simple.
Also you could look into using a tool such as RVM for managing ruby installations, RVM makes it very easy to deploy new versions of ruby into any environment.
http://rvm.beginrescueend.com/
And bundler:
http://gembundler.com/
The whole ethos of Ruby and Rails is based around portability and transparency. Once you start developing with it you start to see how easy it is to redeploy your app to other environments.
If you use a distributed version control system like git, you'll be able to pull down a copy of your application to any machine connected to the web.
Capistrano is also something you might want to look at, its a deployment tool and if you couple it with a version control tool such as git, you have a very powerful combination for pushing updates/changes to your deployed application
You can use Carbon Copy Cloner (http://www.bombich.com/) to copy your HD to another, which you can boot from. Also, if you use TimeMachine on another drive/network drive, then you can restore another machine from the backup.
I have a Rails app that is stored in CVS because that is our corporate standard. It needs to be deployed to a single production server that is running Rails using Apache and Phusion Passenger.
About the production server:
RedHat Enterprise Linux 5.1
The app is used internally at our company, not hosted externally.
I have root access and can install necessary software.
I have ssh access to the box, and can also run cvs there if needed.
Current Solution:
I have been using a patched version (a couple of CVS fixes) of capistrano for this, but it's overkill. (I've looked at vlad the deployer, but it does not support CVS.) I want something simpler, with fewer dependencies/patches.
Desired Solution:
I want deployment to be a single command that checks out the tip of the CVS tree and deploys it.
I want rollback to be a single command that reverts to the previously installed version.
A couple of Rakefile tasks, or a shell script would be fine.
Releases need to be uniquely identifiable--either via timestamp, CVS tag, or some sort of version number.
Capistrano is the current gold standard for Rails application deployment; if you already have it working, why do you want to change it?