Ok, I usually just lurk on jdelist - enjoying all of your discussions but I couldn't stay out of this one.
1. To answer the original question - the only action that should be disallowed during a build (update or full) is checkins. Why? For those us still with TAM files, the record counts get out of whack between gbrspec and either fdaspec and rdaspec - due to the Developer changing something with the check in. This causes the package build to fail. The concept of code not changing while it is 'compiling' to be deployed is applicable to any release (or product for that matter).
This can be done easily by removing 'check in' as an allowed action in OMC. We do this for full DV packages only (with lots of warning).
2. The age old argument - updates vs fulls. We are living proof that updates work - if managed correctly.
We build 9 packages a week - 4 DV, 4 PY (Mon thru Thu), 1 PD on Fri to be deployed on Sun during our IPL outage.
So full packages are just not an option for us.
We are Xe SP32J1, iSeries, web client (80%), TSE, 800+ concurrent users.
We manage to change code at an astounding rate without too much weirdness.
Facts:
- we have gone well over a year without building a full package (not recommended but hey...), for DV...so 4 x 52 = 208....+ not sure how many others...
- we try to build fulls every 3 months but realistically it is closer to 6 months
- we have about 80 developers (some skilled, some not) and manage 100's of objects changing every week (including the oh-so-fun DD items)
- the Developers do NOT have to understand CNC - we have a strict regimented process based on time and OMW statuses that either allow/disallow actions - ie touching an object while it is in a build
- we keep the web client in sync with any package changes (we have to or else chaos would reign) so do a gen for every package built. (full gens go to a side lib so as not to interrupt anything)
So in summary - anything is possible with E1 - providing you follow standards and strict change control.
If you want the complete painful details of how we manage code, I did a Collaborate 2007 presentation that is in the Quest archives.
http://questers.questdirect.org/index.php?mo=do&op=si&topic=1428&type=0
Page 8
20960:EnterpriseOne Technical Change Management
All the same principles apply, regardless of what release you are on. The only difference between Xe and 8.12 is that things are MUCH easier on 8.12. One of the primary reasons for our 8 non-PD packages weekly is to get the code changes to the web client for testing.
Oh and as for the boring part - this process is so automated now that we have a co-op student doing it - one on an 8 month term and there is a 2 month overlap with the next student so he can train the next one...and so on.
As for lazy developers, the solution is simple. If they don't follow the rules, their code doesn't get in the package. Which equals angry clients and annoyed supervisors. We don't have much of a problem. The biggest issue is code not checked in through the correct project so transfers from DV to PY fail. Again - if it fails, it doesn't get transfered. It only takes a few of these for them to get with the program.
Moral of the story - yes, you too can do update packages (but don't allow checkins of the objects building).
Hope some of this is useful. It was fun ranting anyway.
Sue Shaw
Shell Canada
Xe SP23J1 iSeries stuck in coexistence (sigh)