On 08 Nov 2010, at 7:03 PM, jhumble wrote:
Two reasons: one, the faster you get feedback on the part of the
story you
have done so far, the faster you know if any further work is going
to be
valuable, and what in fact the next most valuable thing to deliver is.
How do you handle branches?
Second, most of the pain of the software delivery process comes
*after* the
software is dev-complete, during testing and deployment (often
called the
"last mile"). One of the important points of cd is that by creating
deployable software with every commit, you avoid the pain at the end
of the
delivery process.
We have an alternative approach to this that we've found works just as
well if not better - we require our developers to integrate their own
code into a package. Until the code has been packaged, the developer
is not done. We've chosen RPM as our packaging format, but any format
that is deployable atomically will do.
We have further automated the deployments so that the packages are
built in dedicated CI instances, in the process making it impossible
for anyone to deploy anything that hasn't come out of source control
first - no dodgy working copy builds or manual tweaking.
We've banned deployment documentation - if you want it installed, you
have to roll it into your package. If you want anything more
sophisticated than "deploy this RPM, graceful restart this service",
you have to justify it.
We've found that doing this reduced costs on our platform by about an
order of magnitude.
Regards,
Graham
--
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
