I don't think noops pose any fundamental problem with deployment. I've
found that straightjacket too limiting preventing me from utilizing
the scripts in situations where one stage may have a role and a
different one does not.
If you elect to use the patch and you still need to verify that
members of a specific role exist it's simple enough to make a task
that raises an error if they don't exist. I use noops and have never
had to explicitly write a test for this nor have I had a deployment
problem where using noops interfered or left a deploy in an abnormal
state. Not to say that it's impossible. It's just for me a missing
role where one should be there is evidenced in other more significant
ways. Like when I go to enumerate that clusters roles. Yes I
dynamically build the role membership from our ec2 clusters since they
can dynamically scale so you would think my deployscripts would be
especially sensitive to the noop issue.
Unlike the typical usage of capistrano where the deployscripts reside
in each application where I found there would be a lot of duplication
we have our own repo just for the capistrano scripts.
I built a multi-stage framework and multi-app framework. In that
framework I memorialize all of our institutional knowledge. Some of
the tasks we have have nothing to do with the apps we deploy.
A typical cap task for us might be
Cap production rsyslog:restart
There's no application involved
Or
Cap testing signup deploy
Which deploys our signup app to our testing stage
A use for noops:
We use the same deploy scripts to refresh app instances that start on
ec2 independently of each other by putting the deployscripts directly
on the appserver and referencing a specific stage that scopes the app
role to localhost and doesn't set the other roles such as web,
memcached, and db
Cap local meta deploy
Local is what sets the roles
Meta is a task sequentially deploys each application that we require
Without noops the scripts would immediately fail because of the empty
web role. With noops it just skips the tasks that have empty roles.
No harm no foul, and we were able to leverage all of our institution
knowledge without having to rewrite it in another framework like
puppett or chef.
I don't have the URL for the patch but check lighthouse and search
this list I posted the monkeypatch I use in my deployscripts a while
ago The patch on lighthouse also included unit tests.
Lee do check that patch out it adds the ability to enable noops with a
default of the current functionality of raising an error so users who
don't care about noops don't need to enable them.
On Feb 10, 2010, at 3:32 AM, Lee Hambley <[email protected]> wrote:
Robin, there's a patch for this somewhere in lighthouse, it's not
supported because having noop tasks run when they're not needed
defies the purpose of deployment. (Yes, I notice you are doing
puppet stuff)
Having noop tasks run as part of a deployment in my opinion makes it
less clear how you are deploying your company's most valuable
resource, and dilutes the clairty of your deployment process...
The patch allows a task to not run if no servers match the role.
You may also want to look at using environmental variables on the
command line to specify single hosts, or roles. e.g.
$ HOSTS=example1.com,example2.com cap deploy
$ ROLES=app,web cap deploy
-- Lee Hambley
Twitter: @leehambley | @capistranorb
--
* You received this message because you are subscribed to the Google
Groups "Capistrano" group.
* To post to this group, send email to [email protected]
* To unsubscribe from this group, send email to [email protected]
For more options, visit this group at http://groups.google.com/group/capistrano?hl=en
--
* You received this message because you are subscribed to the Google Groups
"Capistrano" group.
* To post to this group, send email to [email protected]
* To unsubscribe from this group, send email to
[email protected] For more options, visit this group at
http://groups.google.com/group/capistrano?hl=en
