Up until now I've been deploying Rails apps to our Apache/Passenger setup using a simple Rake task that I wrote. I haven't tried to mess around with Capistrano or Vlad the Deployer.
However, now more developers are coming on board, and I'm interesting in arranging things so that the deployment process runs the tests first and won't deploy unless they all pass. So I'm revisiting the question.
It's been a while since I looked into this. What are most people doing these days? Still using Capistrano? Writing individual Rake tasks? Something else?
Capistrano is still the standard for typical Rails deployments, yes.
We're using Capistrano and Integrity for a CI server. Integrity is quite easy to hack on and you could really easily set it up to automatically deploy on a pass of all tests, and I'd recommend all of them as good tools; Integrity has plenty of plugins available. We currently have Integrity spit out each build's pass/fail and code coverage % into an IRC channel and manually deploy.
Related
I've been working with RoR for a while but now I need to work with designers and other developers. Is there a tool like github or something like dropbox where you can share with your team the files but with a URL where you can check live any change. For example for my own I just run Rails s and I can see what happen on my localhost but for a designer it isn't that simple. And also we don't want everybody running his own rails project on his localhost.
So is there a tool or what do you do guys when you have to work with others collaborates?
You consider to use a staging environment?
A staging environment (stage) is a nearly exact replica of a production environment for software testing. Staging environments are made to test codes, builds, and updates to ensure quality under a production-like environment before application deployment. The staging environment requires a copy of the same configurations of hardware, servers, databases, and caches. Everything in a staging environment should be as close a copy to the production environment as possible to ensure the software works correctly.
See the Font
To use it, i recommend you a application like Heroku, after configure, you can 'deploy' your app commiting in a branch (its not real time, but works for your case).
If you have a VM, i recommends you this tutorial: https://emaxime.com/2014/adding-a-staging-environment-to-rails.html
Open questions like this are not really best placed on StackOverflow, which is geared more toward solving specific issues, with provided code examples and errors etc.
However, in answer to your question:
I see you mention Github in your question, but do you fully understand the underlying concept of Git Version Control, or is there a speficic reason as to why it doesn't meet your needs? As far as I believe, it's main purpose is to solve your exact scenario.
https://guides.github.com/introduction/git-handbook/
Can someone explain to me what the Rails environments are and what they do? I have tried researching myself, but could not find anything. From what I gather, the environments are:
Development
Productions
Test
Each "environment" is really just a config. You can launch your app in various different modes, and the modes are called "environments" because they affect the app's behaviour in lots of different ways. Ultimately, though, they are just configs.
BTW you can't have looked very hard when you looked "everywhere", because i just googled "rails environment" and the top result was this
http://guides.rubyonrails.org/configuring.html
which is the official explanation of configuring the rails environment.
From what you have provided in your question, it seems that you are asking:
"What are the difference between each environment configuration in Rails?"
Rails comes packages with 3 types of environments. Each have its own server, database, and configuration. See Rails Guides: Configuration for more information on options available to you.
Setting up the environment
To set your Rails environment, you will want to enter in command line:
export RAILS_ENV=<env>
Where <env> can be test, development, or production. Setting this environment variable is crucial, as it will determine what gems are installed, or what env is touched when running rails console or rails server.
Included in configuration is the gemset used for the app. When you run rails new, you will find a Gemfile with groups test, development, and production. These groups correspond to the environment currently set. When the environment is set to one of those, running bundle install installs all gems related to that group (and gems not listed in a group).
Included environments
test is designed for running tests/specs. This database will likely be bare bones, except for seeds you may call before running the suite. After each test is complete, the database will rollback to its state before the test began. I do not recommend launching rails server, as running tests (via MiniTest or RSpec) will do this for you, and close the server once the suite is finished.
development allows you to "test" your app with a larger database, typically a clone of production. This allows you to test actual real-world data without breaking production (the version that customers or end-users will experience). To view the development environment in action, change the RAILS_ENV and launch rails server. This is good for deciding how you want your pages to look (CSS, HTML). It is also good practice to briefly "test" your app yourself, clicking around making sure everything "looks" good and the JavaScript works.
production is reserved for the customer and end-user. Configuration includes the actual domain of the app, which ports to use, and initializers or tasks to run. You do not want to play around with your database, as it may be customer-impacting. Ideally, the app should work as best as it can, since this is considered your "final product."
Here are some good reads about Rails Environments
http://teotti.com/use-of-rails-environments/
and
https://signalvnoise.com/posts/3535-beyond-the-default-rails-environments
good luck !!
We have a website using Rails 2.3.x, bundler, nginx, passenger and git, and would now like to use the same code to deploy a very similar site. Differences between the two will include:
Locale
Databases
Validations in some cases
Views in some cases
What is the best way to manage these differences while using the same code base?
Some ideas we've had:
Create new Rails environments, such as production-a and production-b and handle differences in the appropriate environment files. One potential problem is that many gems and plugins are hardcoded to look for production or development environments.
Use Passenger to set a global variable or use the domain per request to determine which context to use. The problem with this are rake tasks, cron jobs, etc that would not have access to this state.
Maintain two versions of the config directory. This would be inconvenient maintaining 2 versions of all the config file, many of which would be identical. Also, I'm now sure how to leverage git to do this correctly.
Any ideas, tips, or examples would be greatly appreciated! Question #6753275 is related but seems incomplete.
One solution I have used in a rails 2.3.x project was to convert the entire site to an engine. That actually is pretty easy, create a folder under vendor\plugins\ and move all the app stuff there. You can see an explanation for rails 2.3 here.
If needed you can even move all migrations and stuff there as well, and use a rake task
to run those.
Everything that needs to be overruled can then just be placed in the actual rails project using the engine. So you would have two rails-projects, with their own configuration, locales and some local overrules, and one big shared plugin/engine.
We used git submodules to keep the code in sync over different projects.
In rails 3 this is even easier, since the engine can now just be a gem.
Hope this helps.
Although Rails and PHP have different deployment methods, what is the preferable way to distribute a FOSS Rails app? Suppose one of the major PHP apps - Magento, Drupal, Wordpress had been build upon RoR, what would have been the preferable way for them to have distributed their application?
Packaging up the code as a gem seems to be the wrong approach for a complete out-of-the-box application, but I could be wrong.
Coming from the world of PHP with its upload-and-go approach, and being a newcomer to Rails, it's rather opaque at the moment to see how code could be easily and effectively distributed.
Packaging a completed Rails app as a gem is probably the wrong approach. I think the best solution is to provide access to a git repository or a tarball of your git repo.
If you want to offer your users something more than rake db:schema:load to setup your app it's pretty easy to create custom setup commands.
Many applications are packaged with the source code just like typical PHP applications. While deploying Rails applications may seem difficult its expected that the user will know how to set up the server properly according to their environment and needs. The only issue you need to worry about is distributing the code, setting up the server is not a domain that you are going to want to help with.
For information on deployment in Rails you should see the deployment page here.
Well, usually Rails apps run in environment running Apache + Passenger (aka mod_rails).
Deployment is easily done with Capistrano gem.
When you're running Rails app in shared host environment, they usually use fcgi/cgi dispatchers to run Ruby.
I've been spending the last few months on developing a (my first) Rails application all by my self, just me and my Linux box, all in my development RAILS_ENV, no SCM ("for shame!") or anything. It has become quite the beast now and I am getting ready to release it onto the world. My question is: how am I ever going to make this work?
I installed gems, plugins, servers (MySQL, node.js, nginx, sphinx, juggernaut), photo compression apps that I call, video compression tools (FFMPEG) etc, I also obviously have a DB and a (lot of) seed data. I can't even remember all the things I did to my system to make it all work, but it does.
So now, when I deploy this on some stranger's server, how do I make sure that all those things get installed and configured correctly? How is e.g. FFMPEG ever going to get installed on this server when I deploy my application. How will the seed data get uploaded, how will the servers get started, with the right parameters etc.
I have read (a little bit) about Capistrano which seems to be the deployment tool of choice in the Rails community, but I am not sure if that will cover all my needs. For example, how do I figure out all the gems I used or the plugins (do I even need to know?). Is there any way I can test the deployment on my own linux box,the same I am developing on, i.e. pretend that I am hosting my own production server/rails_env and "deploy" it there?
Any help will be much appreciated.
Cheers.
There a lot of standards to follow that make life easier...
As far as figuring out which gems you need, you could try and use RVM and make a local config that you keep adding gems to until your app works. This will be kind of like starting from scratch so that you are sure to know precisely what configuration you need to run. (And it should make it easy to stand up a new, identical environment each time.)
The RVM route will allow you to test in a specific environment, which should help.
You can list the required gems in your environment.rb file so that the server demands them on start-up.
Good Luck, Cowboy .