I'm currently looking into what language to build a web application on that will be sold to companies. To make things easier, I was hoping to package the webapp into a convenient installer that contains the entire stack which will run automatically.
Is there any way to create a self contained RoR package?
The only project I'm aware of is called pkgr, which bundles an entire rails app into a DEB package. So if you don't mind limiting your installs to Ubuntu/Debian, you could give it a try.
pkgr home page
Github
You can write a rake task to automatize everything for you. Migrations, bundling, enviroment setup. And it's pretty much plain Ruby, too.
In the end it would be just running a script file to do the job.
Related
How do I create a gem project nested inside my current Rails project?
I've got a Rails project with several parts that could easily be gems. I would like to extract these parts into gems but not leave the current Rails project. Creating new source control repos for the gems add additional complexity that project or organization is not ready or able to handle. These complexities will be overcome at some point and I would like to be ready.
So far I can only think of these items.
Relocate code to a single directory root. I'm guessing this would be in the vendor path
Create a <something>.gemspec
Link to the gem in the Gemfile of the Rails app
gem 'my_lib_code', path: 'vendor/my_lib_code'
What else do I need to do? I'm sure I'm missing something important.
If this were a c project I would create another shared library that the make process spits out. Or if this where a c# project I would make a .dll. For Java I would...
I'm sure Ruby can do the same as all the other languages. Something that is a half way step between a normally fully extracted gem and just some code siting in my lib path.
This is a perfectly fine approach for a component-based architecture.
You have a single repository, a single test suite, and a single deployment process, while at the same time you are "forced" to think of clean interfaces and separation of concerns.
Of course if you are planning on sharing this functionality with other projects, an externally hosted (but not necessarily public) Gem would serve better.
Implementation wise, you can get some nifty ideas from Stephan Hagemann's talk at this year's RailsConf: "Get started with Component-based Rails applications!"
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.
I'm in the process of creating my first rails plugin and am finding managing version control of the plugin and testing app rather annoying.
Here's my problem:
To actually test my plugin in action I need to run it within a test application (which is basically just a scaffold app where I install the plugin)
When I'm making changes to the plugin, it's convenient for me to change it within the test application so i can immediately see the changes come through. However, when I want to commit and push my changes back to github I end up copying all the files out of the test app back into my "naked plugin" folder and doing my commits.
Is there a better way to manage this without copying files back and forth? I'm interested to hear from other plugin developers if possible on how you manage this situation.
One potential solution I've conceived of is to have another git repository within the vendor/plugins/myplugin directory (which will have the remote repo of github). Im not sure if this is best though (and so far I haven't been very successful in making it work...)
I recommend to use git submodules, check a detailed description.
I create a soft link in the vendor/plugin directory to point to the plugin source code.
If you are on Windows you can use the junction tool to create a softlink.
E.g:
c:\test_app
vendor
plugin
foo_plugin -> points to c:\foo_plugin
c:\foo_plugin
lib
Submodules are going work best I think. What I don't like about developing plugins is that you're always starting/stopping the script/server. Without knowing what kind of plugin you're building, I'll just assume that you're building an abstracted class of some kind.
I personally think the best way to go is to develop the class in the lib directory of your rails app. Once you get it about 99% done, then move the class into the lib directory of your plugin. Then commit the changes to the plugin repo.
If you're willing to package your final plugin as a gem, then there is a much easier way. In your basic scaffold app, inside your Gemfile you can point to a local path:
gem 'foo', :path => "../foo"
This way your scaffold app and engine/plugin are in two separate directories; two completely unrelated git repos. You don't even have to start & stop your scaffold web server when you make changes to the plugin (at least in rails 3).
I just wrote up a tutorial for how I created my first rails engine and I extracted the foundation into a good starting point for other engine builders:
http://keithschacht.com/creating-a-rails-3-engine-plugin-gem
As an end user of a plugin, I think it's much easier if it's packaged as a gem. Not only is more functionality possible with a gem, developers can install it once and use it in many apps, dependencies can be easily handled, upgrades are as simple as changing a version number, and you don't have to store the entire plugin in your main app's repo.
When I build Rails applications I find myself doing the same things over and over again. This includes adding the same gems/plugins, configuration info and custom initializers, rake tasks etc... etc....
This can't be a good thing.
So, is there a way to package all this repetitive code into some sort of project template ... so that I can do a "rails myapp" and have everything good to go from there?
Btw, running 2.3.5 if that matters :)
thanks
App templates is probably the feature you are looking for.
Many people just create the "template" and then commit it to a repository, possibly on GitHub, for easy access later. I personally find that this works really well.
I posted this very same item on SERVERFAULT, but got no reply. So here goes:
I'm currently in the process of finishing up a Rails application. I am using Warbler to package it up as a ".war" file and am using GlassFish to deploy it. I do this because the application is to be distributed to companies for in-house use. Arguably i could/should have used another framework to develop an application of this nature, however, I chose ease/speed of development over deployment hassle.
That said, I've got the setup working reasonably well on my development machine. However, I'm curious as to how to go about automating environment initialization. In other words, I need to figure out how to ensure that all DBs, files,etc. are configured upon deployment.
All of the examples I've seen thus far assume you're running your IDE on the system to which you wish to deploy and they have you run your rake tasks manually before deployment. However I need to simply give the end user the ".war" and be able to run all rake tasks upon application deployment/launch.
Can someone point me in the right direction regarding this? FWIW there is nothing in the Glassfish manual about environment initialization etc. -- then again, I don't suppose I should expect them to cover every single aspect of deployment.
Best.
Depending on your database requirements you can embed Derby within the Glassfish environment. You can easily create a blank/default database and then put that clean version in each Glassfish environment you have to set up.
I'm not sure what else you need to configure and initialize, but I'd say that if you can, script it up, either with some rake tasks. Embedding Derby takes care of database startup and initialization. Remember that a war file is just a zip file, so adding config files via a script shouldn't be so hard. You can use rails initializers (/config/initializers/) to load up yml files for configuration or whatever you need to do as the app starts up.
You won't be able to have the intializers create the schema in the database, but you could have them check for default seed data and put it in if it isn't there.
You should be able to access any part of the file system that Glassfish and the JVM can access. I don't know much about Glassfish but the only problems I've had with jruby rails apps on Tomcat were related to relative paths being relative to where the startup script was called from, and not always relative to the installation root. This could probably be solved with the right startup scripts in Tomcat or setting the appropriate start-in folder, I just haven't had a need to dive in to that very much.