[Anthill-pro] How do you manage changing deployment processesandolder code?

Brian_Kelly at timeinc.com Brian_Kelly at timeinc.com
Tue Nov 3 16:38:11 CST 2009


We've made a lot of changes that don't require changing the interface
(refactored the implementation without affecting inputs and outputs) but
occasionally a change to the interface is required.

In this particular instance I need to separate out the undeploy step and
run that on a set of "slave" Agents before deploying the updated code to
a "master" Agent. Then I deploy to the "slaves". This is so the slave
machines don't get upset that the master is missing which ends up
causing the slave machines to get upset... and typing this out makes it
sound more like an architectual issue.

Anyways, in this case the actual Workflow is changing as well as there
being some additions to the Ant script.

I guess I'm curious how often this happens for others and how you deal
with it.

-brian 

-----Original Message-----
From: anthill-pro-bounces at lists.urbancode.com
[mailto:anthill-pro-bounces at lists.urbancode.com] On Behalf Of Yanko,
Curtis
Sent: Tuesday, November 03, 2009 5:27 PM
To: AnthillPro user and support list.
Subject: RE: [Anthill-pro] How do you manage changing deployment
processesandolder code?

Do you have to change the interface (calling a different target)? You
should be able to hide the implementation behind that interface so that
how you call the deploy script doesn't change even if how it does it
has. 


==========
Curtis Yanko
Application & Developer Infrastructure Services Continuous Integration
W: 860.702.9059
M: 860.881.2050

-----Original Message-----
From: anthill-pro-bounces at lists.urbancode.com
[mailto:anthill-pro-bounces at lists.urbancode.com] On Behalf Of
Brian_Kelly at timeinc.com
Sent: Tuesday, November 03, 2009 4:42 PM
To: anthill-pro at lists.urbancode.com
Subject: [Anthill-pro] How do you manage changing deployment processes
andolder code?

We've come across a few situations where the deployment process has to
change and it can invalidate the deployment scripts of older builds.
The majority of our projects are WAR files that need to be deployed to
multiple servers. Our deployment strategy consists of an Ant script
(deploy.xml) and an associated AHP Wokflow and Job.
 
For example, the Workflow might call 3 Jobs:
- Environment Verification: deploy.xml "verify" target on each host
- Tomcat Deploy: deploy.xml "full" target on each host
- Deployment Success: job to label the build with the environment short
name
 
Now I need to add a new step which calls an "undeploy" target inside
deploy.xml. This will work fine for the trunk of the project, but other
branches (and earlier builds) won't have this new target so they will
fail.
 
How do others handle these kind of changes? How do you make sure one
version of a Deploy workflow works with certain builds and not with
others? Do differing deployments warrant separate projects?
 
-brian
_______________________________________________
Anthill-pro mailing list
Anthill-pro at lists.urbancode.com
http://lists.urbancode.com/mailman/listinfo/anthill-pro

This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity to
which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.

_______________________________________________
Anthill-pro mailing list
Anthill-pro at lists.urbancode.com
http://lists.urbancode.com/mailman/listinfo/anthill-pro


More information about the Anthill-pro mailing list