altquark
Legendary Poster
Top 10 reasons why Developers should NEVER be able to promote projects or build packages...
I have a customer - who is currently running OneWorld Xe. Quite large, their implementation has several hundred users and given the amount of customization - they have a large number of full time OneWorld developers.
So, the question being posed is "why shouldn't developers have access to be able to promote projects to PY and build PY packages". Their reason is (as stated) because "waiting for CNC to build packages is delaying their testing".
I'd like to create a list in a public area like this to protect companies from their own ignorance - and so I'll kick this little holy war off with my own reasons.
1. In a public company, SOX requires that changes to production are NOT applied by the developers (segregation of duties)
2. Package builds MUST be performed on a centralized, individual basis. Multiple builds cannot happen in parallel (corruption of packages)
3. If developers have access to promote/demote objects - then this will become abused since developers will "fix" objects without other developers knowledge - the "token" system becomes useless
4. Developers usually have no idea about how to troubleshoot package build issues or promotion issues. They can barely troubleshoot why their own objects can't be checked out...
5. Package builds/promotions require access to the system MUCH higher than development access. This could therefore become abused, even without the developers knowledge.
6. To troubleshoot a build issue on the enterprise server requires access to system code on the enterprise server. Again, this access could result in abuse and security breaches without a developers knowledge.
7. Promotion of certain objects AUTOMATICALLY updates an environment - and needs to be carefully managed otherwise users can be severely impacted.
I'll stop there - but I'm sure that others can enlighten this thread.
Heres my proposition. Developers should ONLY have access to development objects - and should NOT have access to promote projects. Access to PY should be limited, and only if a business analyst (tester) has an issue and it requires troubleshooting. Developers should have the ability to promote from "21" to "22" - or some other "dead" code in OMW to mark a project as being ready for promotion to PY. Someone else (a development manager) should then identify whether all the documentation and individual development testing has been completed by moving this from "22" to "23" - ie, ready for CNC to promote. CNC then picks up all projects at a set status on a known, regular schedule (daily) and promotes from DV to PY.
DV packages should RARELY be built - I say developers should "get" whatever objects they need. You don't know what objects ? Check cross-reference (I always give developers those type of tools). Developer package deployments usually result in a developer losing work, and once is too many times. I build a full development package about once a month or even less regularly.
I await comments(!)
I have a customer - who is currently running OneWorld Xe. Quite large, their implementation has several hundred users and given the amount of customization - they have a large number of full time OneWorld developers.
So, the question being posed is "why shouldn't developers have access to be able to promote projects to PY and build PY packages". Their reason is (as stated) because "waiting for CNC to build packages is delaying their testing".
I'd like to create a list in a public area like this to protect companies from their own ignorance - and so I'll kick this little holy war off with my own reasons.
1. In a public company, SOX requires that changes to production are NOT applied by the developers (segregation of duties)
2. Package builds MUST be performed on a centralized, individual basis. Multiple builds cannot happen in parallel (corruption of packages)
3. If developers have access to promote/demote objects - then this will become abused since developers will "fix" objects without other developers knowledge - the "token" system becomes useless
4. Developers usually have no idea about how to troubleshoot package build issues or promotion issues. They can barely troubleshoot why their own objects can't be checked out...
5. Package builds/promotions require access to the system MUCH higher than development access. This could therefore become abused, even without the developers knowledge.
6. To troubleshoot a build issue on the enterprise server requires access to system code on the enterprise server. Again, this access could result in abuse and security breaches without a developers knowledge.
7. Promotion of certain objects AUTOMATICALLY updates an environment - and needs to be carefully managed otherwise users can be severely impacted.
I'll stop there - but I'm sure that others can enlighten this thread.
Heres my proposition. Developers should ONLY have access to development objects - and should NOT have access to promote projects. Access to PY should be limited, and only if a business analyst (tester) has an issue and it requires troubleshooting. Developers should have the ability to promote from "21" to "22" - or some other "dead" code in OMW to mark a project as being ready for promotion to PY. Someone else (a development manager) should then identify whether all the documentation and individual development testing has been completed by moving this from "22" to "23" - ie, ready for CNC to promote. CNC then picks up all projects at a set status on a known, regular schedule (daily) and promotes from DV to PY.
DV packages should RARELY be built - I say developers should "get" whatever objects they need. You don't know what objects ? Check cross-reference (I always give developers those type of tools). Developer package deployments usually result in a developer losing work, and once is too many times. I build a full development package about once a month or even less regularly.
I await comments(!)