Author notes: This document is template for Project Managers or Team Leaders that have to define / scope and document the process for the organisation.
Version: 0.1 for Word / OpenOffice.
This document is not for technical teams, but to be used as a template for any manager or team leader that is faced with having to produce a control document for the organisation.
There are a number of references to other documents that I have left in as I based this on a specific component within a system delivery cycle.
I.e. these are typical dependancies on the organisations overall document and procedural controls.
I would like to have spent more time refining this, but I am about to continent hop again, so I probably won’t get a chance to revisit for a while. XI3 Dev-LifeCycle Management Template.zip (197.0 KB)
This looks very promising Mike. Appreciate it and thanks much for sharing.
I have a question for you. Thus far what has been your experience with LCM generally speaking? And have you gotten a chance to compare it with any of the existing Third party versioning tool regarding Business Objects yet?
LCM is not a mature product re versioning and yet it does offer some capabilities that I have found to be pretty usefull if dealing with a controlled environment i.e. the dev / test / uat / prod scenario.
Sure, you cannot ‘lock’ content etc but I think many are looking for this feature to bypass the lack of developer and administrator understanding and controls.
To my mind the promote ROLLBACK function is a real bonus - we have an instance where we have to hand over the control of UAT and PROD to another unit that is not BO proficient (bank security …).
We also have to adopt a release package process i.e. no CMS to CMS / only biar and lcmbiar.
A package gets created in DEV and dropped onto a share / it gets picked up in TEST and the original LCM release instruction is overwritten BUT you have the History details to see where it is in the chain.
DEV and TEST can see all the details of specific jobs but don’t have admin access to UAT and PROD so there’s your control.
I adopt another internal control in DEV whereby you MOVE an existing report out of the CORP folder into a PROJECT folder for changes.
Once done you move it back and then create the lcmbiar. This is almost like a check in /check out process as the system is governed by access to the respective folders.
You can also use subversion here but why create a whole new procedural layer if you can adopt good development and admin habits.
I’ve tested a release rollback and it works - partial rollbacks yet to be tested.
The above is achieved without the version management module so I’m only creating baselines for major releases as opposed to creating a new version prior or post object migration.
In summary - LCM does not compare to a true versioning system as applied in a typical development environment, but to be fair, the fact that the BO objects are bound to a closed environment with so many dependancies makes it difficult for the vendor.
Your IDE and Java type worlds have taken years to mature to a point where version control is efficient and practical. The fact that the vendor has started the process is heartening so I would suggest using what is available and making up for the shortcomings with GOOD standards.
To my mind, having teams of pure report developers just churning out rreports without the necessary skillsets and understanding of best practices etc is probably the main issue.
Aside: there is a tool called Tortoise that adds some view etc functionality to the subversion repository.
(BOB member since 2002-06-18)
(BOB member since 2003-11-27)