Change of lifecycle on existing project

[Jarus Bosman]

Goo day,

My user is not happy with the way the Production Model (a project template installed with Harvest) handles merging. Specifically, when a new path is added, promoted to the "Merge" state, merged, then demoted again to add additional items, the merged path is not visible in the Development State anymore. Now he has to backup and delete all items checked in under the same package as the new path, delete the merged path, add it again, and add all the items again. This could happen multiple times before all changes are actually promoted to production. More details on this problem can be found in this thread.

I want to see if we can improve the process, but the problem is that there are now already hundreds of items in different states in the lifecycle. I am concerned that I might cause chaos if I now for example swop the Merge and Test states, so that their testing can happen before any merges take place. Any advice on how to handle this would be greatly appreciated. If we're using the model incorrectly, please also let me know so that we can fix our processes.

Thank you in advance,


------------------------------
Jarus Bosman
Senior Software Developer
State Information Technology Agency
South Africa
------------------------------

[Milton Huston Jr]

I would suggest setting up a test project using the "Production Model" and modify the model to have the Dev and Merge states share the same working view. You would still do all you merging in the merge state but in this case dev would see the branches and new paths being created. When you demote from merge to dev the view would not change.

Worth a try, hope this helps.

[jeff suess]

I'd think we'd need to know more about how the team delivers the software before we could make a recommendation. 

How often do developers merge? Daily? Weekly?

Are teams using peer reviews, paired programming, TDD or CI (where CI is actually defined as integration with the trunk). If so, is the trunk always deployable or is it waterfall?

Deployable source? Built artifacts? 

Which is more common, the migration of individuals package or package groups?

Are feature flags, dark deployments, and abstractions common? What about the partial delivery of features (That is... is it more likely 10 features will be delivered with 1 big change than that one feature will take 10 little changes to deliver)?

How many environments?

Are deployments "no down-time"? If so, blue/green, A/B, saturation, etc... If not, how often do you get a maintenance window? Is there an SLA to go with this?

Are deployments typically dependent or independent of other application change within other applications? 

How long do the test cycles take? Which ones are automated vs manual?

[Jarus Bosman]

Hi Jeff,

It could take a while to give a complete answer to all your questions! I'm going to forward your suggestion to the user and request some of the information.

Thank you for your advice.

Regards,

------------------------------
Jarus Bosman
Senior Software Developer
State Information Technology Agency
South Africa
------------------------------

[Jarus Bosman]

Hi Milton,

That could definitely work. The problem I see with going that route, is that you lose the benefit of having Development and Production share a view, which is ensuring developers always work on the current production version of the source. But that is something they can decide if they want to take the risk of.

I might take some time and test this as you suggested. Thanks for the advice.

 Regards,

------------------------------
Jarus Bosman
Senior Software Developer
State Information Technology Agency
South Africa
------------------------------

[Milton Huston Jr]

Hi Jarus,

Yes, you are spot on with the Prod view and Dev sharing the same view.
Possible moving to a release management model would help, however you would
be pulling latest from the Dev view versus the prod view.
If staying with the prod model I would suggest that you don't demote merged
changes, instead make changes to the branch in dev and promote.merge in teh
merge view.

My thoughts...:)

Regards,

Milt

--

*Milton T. Huston Jr.*

Broadcom

Client Services Consultant, Mainframe Presales

Mobile: *[phone]*

Tel: *[phone]*

*Milton.Hustonjr@ <[e-mail]>broadcom.com
<http: broadcom.com="">*

--
This electronic communication and the information and any files transmitted
with it, or attached to it, are confidential and are intended solely for
the use of the individual or entity to whom it is addressed and may contain
information that is confidential, legally privileged, protected by privacy
laws, or otherwise restricted from disclosure to anyone else. If you are
not the intended recipient or the person responsible for delivering the
e-mail to the intended recipient, you are hereby notified that any use,
copying, distributing, dissemination, forwarding, printing, or copying of
this e-mail is strictly prohibited. If you received this e-mail in error,
please return the e-mail to the sender, delete it from your computer, and
destroy any printed copy of it.