I recently did a presentation on Sinatra at my company (RiskMetrics Group). I thought it would be apropos to do the presentation with Sinatra. To that end, I have created a project on GitHub for this called Sinatra Based S5 Presentations – SinBaSP for short.
I know the name isn’t clever, but oh well. Feel free to fork it or send me patches (with tests/specs hopefully).
I have Capinatra (0.1.0) installed and Capistrano (2.5.3). While trying to deploy to production I got this error:
/usr/local/lib/ruby/gems/1.8/gems/capistrano-2.5.3/lib/capistrano/configuration/namespaces.rb:188:in `method_missing’: undefined local variable or method `app_class’ for #<Capistrano::Configuration::Namespaces::Namespace:0×12060d8> (NameError)
The “fix” was to set the app_class variable in my Capfile (I’m using the DSL style of Sinatra, I don’t have a base class that extends Sinatra::Base).
set :app_class, ”
I think the docs that come with the Force.com Migration Tool are woefully understated. Jon Mountjoy's article is a good overview, but it doesn't do much to help at the nitty-gritty-detail-level. So, I thought I would post this showing how we use the tool.
First things first. What is it? The Migration Tool is just a library that you can embed into your Ant distribution, or that you can reference from the commandline. This library calls Force.com's web services to accomplish its work. For more discussion on this, reference the afore mentioned article by Mr. Mountjoy. I also will not talk about all of the available targets. This will be a use case study.
We use the tool to deploy code to production and to our sandbox. We sometimes deploy small portions of code and sometimes all of it. We also use it to deploy metadata changes.You can view our build.xml in the attached files.zip.
It's pretty simple. The first thing to notice about it is that we have two targets called 'use_prod_environment' and 'use_test_environment'. These targets depend on properties. The use_prod_environment will be invoked if the property use_prod_env is set. We do this from the commandline by specifying -Duse_prod_env=true when we invoke Ant. The same is true for the test (sandbox) environment -- this is actually the default, so if we specify nothing on the commandline the Sandbox environment will be used.The next thing to notice is that we have only 2 other targets retrieveUnpackaged and deploy. These targets depend on the environment targets above which set properties for the Force.com URL, username and password. retrieveUnpackaged always retrieves code from the specified environment to a single location unpackaged under our src directory. deploy depends on another environment variable called deploy.root. This variable tells the Tool what set of resources (code and/or metadata) are going to be pushed to Force.com.
Deploying is the only activity we do that cares about dealing with subsets of files. So to do that we have created more directories along-side the unpackaged directory: limitedRelease, apex, and objects. Each of these directories includes a package.xml that specifies what metadata and/or code is to be pushed (telling the Tool what directories to look for). In truth, you can have the same package.xml for any of these directories (just copy it from the unpackaged directory). What really matters is the directory structure underneath. If you have a classes directory the Tool will deploy whatever classes are there. If you have a triggers directory it will deploy whatever triggers are there. The same goes for objects, applications, letterhead, pages, profiles, scontrols, staticresources, and tabs -- all directories within this directory.
Our 'limitedRelease' directory is a testing ground for new changes. We hard-copy classes and triggers into its subdirectories (along with their associated '-meta.xml' files). We work on that set of code and deploy it to the Sandbox as we test (test-first mind you, which is a little more of a hassle with Force.com, but still doable).
Our 'apex' directory is for all classes, pages, triggers and staticresources. They are all soft-links to the subdirectories under 'unpackaged'. This directory is used to deploy all of these resources to production and/or sandbox, as opposed to the limited set under limitedRelease.
Our 'objects' directory is used to migrate object metadata changes between production and the sandbox. The files under this directory may be hard-linked or soft-linked.The basic commandline looks something like:
ant -Ddeploy.dir=limitedRelease #deploys resources that are currently being developed to Sandbox
ant -Duse_prod_env=true -Ddeploy.dir=apex #deploys code resources to Production
ant -Duse_prod_env=true -Ddeploy.dir=objects #deploys object metadata to Production
ant retrieveUnpackaged #gets all resources from Sandbox
ant -Duse_prod_env=true retrieveUnpackaged #gets all resources from Production
Instead of typing these out all of the time, we use shell scripts which expect to be passed the use_prod_env variable when we want to deploy something to Production, otherwise it's deployed to the Sandbox.For instance our deployApex.sh looks like this:
We keep the Force.com Migration Tool library in a lib directory above our src directory and reference that in our shell scripts.
You can download the files mentioned in this article here.
I am both a Rubyist & a Smalltalker. I enjoy both environments immensely and use them for different purposes. In a recent flurry of posts, James Robertson over at Cincom completely misunderstood the point Neal Ford was making about the meta-programming facilities Ruby offers versus the facilities Smalltalk offers, or better yet the facilities that either tend to use.
Avi Bryant chimed in and cleared the picture up a bit, but I wanted to simplify it even further for those who are still in the dark. Mind you, I do mean simplify.
The issue as I see it is the ability and/or desire to add methods to an instance of an object, rather to its class definition. (I know that you can probably do this in Smalltalk, but I don't know how.) The beauty of meta-programming this way is that we can add a ton of very useful boiler-plate code to an object without cluttering its definition, and the implementation of the new method isn't reflective (thus adding performance penalties).
In a language like Ruby this is key, where the tools are less than capable, and we are still dealing with "source code in files, how quaint" (Kent Beck). In Smalltalk it doesn't matter so much that the code is generated into the class definition, because we don't browse code in Smalltalk the way we might in Ruby.
Of course there are other arguments about why meta-programming this way is good or bad, but I think this is the main point of the discussion at hand.
Someone feel free to correct me if I have been too simplistic.
Powered by WordPress