[Anthill-pro] How do manage shared Life-Cycle Models and competing status/environment configurations?

[Brian_Kelly at timeinc.com]

Hey Eric,

I just tried a quick test of this but ran into the following problems:
1) If no SCM Type is chosen, no SCM steps are available to add to jobs.
This isn't too bad as we are standardized on Subversion.
2) If no Life-Cycle Model is chosen, no Status steps are available to
add to jobs. This seems to negate the point you make below about being
able to provide a script. It looks like this can be done with Stamps
(the Stamp step shows up when no LCM is choen), but not with Statuses.

-brian

-----Original Message-----
From: anthill-pro-bounces at lists.urbancode.com
[mailto:anthill-pro-bounces at lists.urbancode.com] On Behalf Of Eric
Minick
Sent: Tuesday, February 09, 2010 11:03 AM
To: AnthillPro user and support list.
Subject: Re: [Anthill-pro] How do manage shared Life-Cycle Models and
competing status/environment configurations?

Brian there's a balance to be struck here. If the "prod-new" can be
called something like "staging" that might also be a reasonable status
name for another of these other environments, that's great. If not, this
project might require a custom LCM.

One option with the jobs and workflows is to give them a LCM setting of
"none" which means they will be available to all projects regardless of
LCM.
This rules out using things like assigning a status or stamp from a
drop-down list - you would have to use the scripted model.

Regards,

Eric

On Tue, Feb 9, 2010 at 8:57 AM, <Brian_Kelly at timeinc.com> wrote:

> The majority of our projects are Java Web Apps that are deployed in 
> the same manner - using the Tomcat Manager. In order to reduce the 
> amount of duplication of maintenance in our AHP instance I created 
> shared jobs and workflows for building and deploy WARs.
>
> In order for different projects to make use of the shared jobs and 
> workflows they need to be set up with the same Life-Cycle Model. This 
> means they also share the same status.
>
> This starts to cause a problem when I need to introduce a Status for 
> an Environment that is specific to a set of projects but doesn't apply

> to the other groups of projects using the same Life Cycle Model.
>
> I'm currently experiencing this where a project needs to test their 
> builds out on a new non-live Production environment. Currently the 
> Life Cycle Model has the statuses "dev", "qa", "uat" and "prod". In 
> order to differentiate it self from the current live Production I'd 
> need to create a status called "prod-new" or something along those 
> lines. This new status would then show up for other projects that 
> don't make use of this environment. Do this for a few projects and the

> number of statuses starts to get confusing.
>
> How do others deal with this? I'd really like to avoid making separate

> Life Cycle Models for each project which would result in lots of 
> duplicate jobs and workflows.
>
> -brian
> _______________________________________________
> Anthill-pro mailing list
> Anthill-pro at lists.urbancode.com
> http://lists.urbancode.com/mailman/listinfo/anthill-pro
>
_______________________________________________
Anthill-pro mailing list
Anthill-pro at lists.urbancode.com
http://lists.urbancode.com/mailman/listinfo/anthill-pro