Allowed Activities During Full Package Build

Hey Guys,

When it comes to CNC I am a novice. However, I just have to ask this one. Oh and I did try to find it first.

I am developing at a new client and their CNC person says that in order to do a build all objects need to be checked in and no one can check out an object during the build. Now I know I have been developing and checking out while package builds were going on. Heck, one client would even make the check-in button invisible during the builds.

So is there a situation where we shouldn't be developing during a package build, and what activities can or can't go on during a package build. I badly need enlightenment.

Thanks in advance,
Ben again

Ben,

Look, it's a bit complicated: in some cases JDE would not include an Object in the build at all, if it's not checked-in (i.e.: BSFN's). This, of course, will cause problems. And naturally they will be able to trace it back to you.

In other cases - this would have no effect, because the build dumps entire specs tables into TAM (or MSDE/SSE) no matter what.

Generally, they are correct: you shouldn't.

But occasionally this may go unnoticed and without any bad side effects, i.e. if it's some humble Version...

Basically, unless you are 100% sure, don't. ;-)

Ben,

It's not that you can't develop during a package build, it's just that you need to resist the urge to checkin or checkout objects during the first two hours of a full package build. At least in XE, not sure about the newer releases, the first two hours are critical. That is when the client is being built and the deployment server is gathering all of it's code to compile. When it comes to the server build, it lobs the gathered code over the fence to the enterprise server. In our shop, we build a full PY and a full PD every week. I have a set day and time that I build. If the developers need more time, they call me up and I hold off on submitting the package until they are all checked in.

Gregg

As of my knowledge..................

While DV Client build Running We can do Development....and we can do check out for objects
But.....
We can't do check in for objects.
If we can do check in for objetcs then u can lost all u r specifications.

Actually, check-outs have zero effect during the build.

Like Alex said, if the object has never been checked in, you will have build issues. If its interpretive code (ER, reports, forms, etc.), the issue is negligible because the object just will not work if it is run. If its C code, you will have Busbuild errors that could mess up your build and the apps that use the BSFNs.

It gets messy when you check in interpretive code (ER, reports, forms, etc.) during the build. The problem is that the build does not build objects serially. For example, a P55 app. It builds the form specs separately from the event rule code for the app. So, depending on when you check the app in, the form code may be built in fdaspec.ddb but the event rule code will not exist in gbrspec.ddb. So you end up with an app w/o event rule code.

Builds run off of whatever is in Central Objects as the build is running. The exception is the C code. The C code gets copied before the build. The Central Objects (interpretive code and versions) are not shapshots though. The solution to this problem would be to have a snapshot of the Central Objects DB and the data dictionary DB at the time the build starts. I doubt that JDE-Oracle will implement this kind of thing anytime soon.

The sad part of all this is that I don't think JDE includes this information in their documentation. They assume all builds are done after hours. I got tired of dealing with developer issues so I do all full builds after hours. Essentially there is no debate on what was in Central Objects and versions when the build started. Also, my builds take less than 4 hours.

Yes. Full package builds in DV should be done after hours or planned for weekends. DV full packages should be done VERY VERY rarely - like hardly EVER unless a service pack is installed in my opinion - since testing should occur in PY and not in a rapidly changing development environment.

While a package build is being performed - then in that pathcode, nothing should be checked in if it were already checked out. Usually the only real issue comes with modification of JDE business functions or data structures. However, best to just build the package when developers aren't logged in.

[ QUOTE ]
qoute from gregglarkin - In our shop, we build a full PY and a full PD every week. I have a set day and time that I build. If the developers need more time, they call me up and I hold off on submitting the package until they are all checked in.


[/ QUOTE ]

When you are building every week do you also do a full jas generation and deploy every week also? Just wondering about the following if it happened in this order:

Full Client and Server Build
Full Jas deploy
Update1 package and Jas deploy for update
Update2 package and Jas deploy for update
Full Client and Server Build

In this scenario, do I need to do a full jas deploy again since the jas objects are already updated.

thX.

Grant

Grant,

I do a full PY client and server. The server is deployed to my test batch server. The Client to my two test terminal servers. My full PD package goes to all of my batch and enterprise servers. The client goes to all of the production terminal servers (18 at the moment). I take a 60 minute outage early onn Saturday mornings to finalize the PD deployment. The web server is insignificant in my environment. I think the last web generation was three years ago.

Gregg

Greg doesn't run web (I believe) so there is no JAS generation for him (his shop runs Xe).

However, yes - in a web environment you would also have to run the JAS regen immediately after performing a full package build. So the process would be as follows :

Full package build (client and server)
Full package deployment - JAS machine and App Server(s)
Full JAS Regen (requires web users to be logged out)
Restart of JAS services

Update1 package build (client and server)
Update1 Package deployment - JAS machine and App Server(s)
Update1 JAS Object regen (manually typing in each object)
Restart of JAS services

Update2 package build (client and server)
Update2 Package deployment - JAS machine and App Server(s)
Update2 JAS Object regen (manually typing in each object)
Restart of JAS services

ad infinitum....

In some very large shops, with lots and lots of development occurring (daily promotions to PY and weekly to PD) then gregs' system is the accepted norm - a day is usually set aside for all packages to be deployed and all the developers know of the day and time. At one customer I usually do PY packages on a daily basis, and PD update packages twice a week (tuesdays and thursdays) with an option for a full PD package about once a month over a weekend (and would inform the users prior to this). That customer has a half dozen full time developers - so its a medium sized development organization. If you have less developers - then you will probably have less need for package builds - down to customers that run "vanilla" and only do package builds when JDE tells them to !!!!

Large development organizations - like Gregs and others out there - have multiple CNC specialists and in-depth procedures to handle lots of parallel package builds. Now you are starting to see the challenge if you have more than the standard set of pathcodes OR if your package build takes a long time to complete !

If you're interested - I have a number of whitepapers on my website that discuss package naming conventions, OMW Configuration recommendations and the challenge for additional pathcodes.

Jon is mostly correct - we have a webserver but it is insignificant. We do have multiple CNCs, but we are focused on different systems. I do North America, and then we have another guy specialized on Asia. We provide backup support for each other. My boss provides a bit of backup support and we are slowing training a new guy on some of the simple stuff.

Thanks for clarification and quick replies!

Sorry, you're totally wrong on this one. I've read your stuff before but you're wrong.

If you are working on an install with more than 3 developers, you are just asking for trouble with update packages. I work on installs with 10 to 100 developers.

Here's the top 10 reasons why full builds work:

1. Update packages force developers to understand CNC. Most developers don't and will never want to.

2. No Change Control Forms tied to builds.

3. With full builds, its either checked in or not. If its not checked-in, it can be in the save location if the developer chooses. No more debate over which versions were or were not in the build. No more debate over whether an objects was modified or not. No more debate over timing.

4. Full builds are more reliable in build and deployment.

5. No more concerns about recompressing parent packages
-or- not compressing the parent package. Or, whether compression works with update builds.

6. Full packages are a snapshot in time, updates aren't.

7. In 8.12, there isn't any serialized object generation. Its part of the builds so generation is not an issue.

8. Properly configured deployment servers can do a full build in 4 hours. For an update build, I spend 1 hour on the build and 3 hours explaining change control, CNC, development tools and package builds to semi-trained developers and project managers. The amount of time is a wash.

9. Hardware (network and servers) to support package build processing is becoming much cheaper than the lost productivity caused by the eight items above.

10. Package builds are a non-value add process, boring and I hate wasting time on them.

If you look at the history of CNC, Oracle's design is beginning to de-emphasize update builds anyway. Fat clients are gone. Developer's can test everything (web, reports, etc.) without a full build on the server using their development workstation.

Ben,

What is your release level? (ie. XE, 8.12)

[ QUOTE ]

Sorry, you're totally wrong on this one. I've read your stuff before but you're wrong.


[/ QUOTE ]

I'll be the first to admit I'm wrong about something - but I fail to understand what I'm wrong about ! I'm assuming you're points are about my statement

[ QUOTE ]

DV full packages should be done VERY VERY rarely - like hardly EVER unless a service pack is installed in my opinion


[/ QUOTE ]

and everything you state supports that statement. Let me clarify.

I NEVER do update packages in development. Ever. I also VERY RARELY do full packages in development. I think if I had stated :

[ QUOTE ]

DV packages should be done VERY VERY rarely - like hardly EVER unless a service pack is installed in my opinion


[/ QUOTE ]

It probably would have reflected better on my view of package builds for developers.

Now to clarify why, from a developers standpoint. Developers modify objects all the time. Lots of objects. They are also pretty lazy - no matter what policies you put in place, you always discover that some developer somewhere has had some business function checked out on their machine - and I _HATE_ having to chase developers up about their stuff.

ok - but developers NEED objects - and in effect a "package build" just does the same process as a "get" - so if a developer needs the latest version of some object for a project they're working on - they they can manually "get" those objects.

If a developer is working on a bunch of objects, and I push or install a new full package - or update package - I could easily overwrite their work. Thats a big no-no. Therefore full packages , when created in Development, should be done based on a developers schedule - because for that pathcode, they are the primary user.

so let me reiterate my badly formed statement. No update packages for development. Rarely perform update packages in Production (for performance reasons) and you're ok doing lots of update packages in PY (CRP) because of time constraints.

DO, however, schedule regular full package builds for all pathcodes - and in most companies, PD should have a relatively frequent full package build, PY should be less frequent and DV is the least frequent (since it impacts all the developers).

Now, there IS one argument that does conflict the above. That is that the developer might not know what objects they need to perform their work (remember, business functions call other business functions). If you're doing a lot of development, its a good idea to have a central client which can be used by developers for testing - for example, set up a virtual client in vmware with single-user RDP (or another remote control software) enabled, and have the developers test their work there. That way, all developers will "get" their work centrally - and if things get out of step, then its an ideal location to deploy a new full package to quickly and simply.

However, personally I think developers know what they're working with - and they'd be able to "get" any objects that might have been modified by someone else since the last full package !

So, in summary - I agree with list6654's points - though he has articulated much more clearly why I stated that Full DV packages should be done rarely and Updates should never be done at all !

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)

And the part that Sue didn't mention is that they have a bunch of CNCs to help manage all of that. So yes Sue, if you have a strong process, you can get by with updates. If you're like the rest of us, you come up with a different process to fit the norms of your company. Hey Sue, try to keep warm up there in the great white north of Canada, eh!

[ QUOTE ]

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...


[/ QUOTE ]

Of course, Sue, your company is one of the non-standard ones out there. You're doing a lot of development - and you have a large team of CNC people. Certainly your model isn't going to be suitable for companies either a lot smaller implementation or running 8.9x. As an aside, however, I did architect a company with 4 times the number of your users (concurrently) with 25 developers - and there is only 2 CNC administrators at that site. Different approaches I guess.

However, I am interested in the performance of your DV package with 208 updates. Obviously the spec files become horribly fragmented after a while - and bloated too. However, since you're web - your end users wouldn't really see any performance issue from those big TAM files...but its interesting to know if your fat clients/Terminal Servers are suffering all the same !

and then there's small shops like ours (2 geeks handling CNC, development, DB admin, user support) who go the update package (every 2 weeks) route also. Full packages happen maybe twice a year.

No problems here with update packages ... <

Its funny the things we pick to have religious wars about, isn't it?

On a different subject . . . How about the Tin Man mini-series on SciFi channel - anyone else watch it?

Then there is the tiny shops, where SOX doesn't apply (non USA), that have one person looking after CNC and Development. We (sorry, this person - OK me, well I) rarely build full packages and mainly use update packages. We (oops, I) follow the following process:

1) Develop in DV in Dev System. If needed for testing purposes build/deploy DV update package (eg. testing UBE on Server).

2) Transfer to PY in Dev System build/deploy/gen update package for User testing - no I don't do the testing

3) Transfer to PD in Dev system - staging environment for product package.

4) Build product package for transfer to PD in Prod system.

I lurk, I might not say too much - but with these really big, interesting threads - its time to weigh in and kick butt.

[ QUOTE ]


Here's the top 10 reasons why full builds work:

1. Update packages force developers to understand CNC. Most developers don't and will never want to.


[/ QUOTE ]

Not sure how a package "forces developers" to understand CNC. However, most people with powerful roles in any ERP organization should have at least an inkling of knowledge of what CNC is and how it works.
[ QUOTE ]

2. No Change Control Forms tied to builds.


[/ QUOTE ]
What is THIS about ? If you want a TPC form filled out, then create the right TPC form and assign it to the update package - not sure why your process wouldn't be able to cover partial updates to be honest

[ QUOTE ]

3. With full builds, its either checked in or not. If its not checked-in, it can be in the save location if the developer chooses. No more debate over which versions were or were not in the build. No more debate over whether an objects was modified or not. No more debate over timing.


[/ QUOTE ]
Save locations suck, and are a crutch for those who do not understand how CNC Architecture works. Just providing a SAVE location to a developer and shrugging your shoulders when that developer loses an object isn't a way to troubleshoot or help developers. CNC Administrators' role is to manage the objects in the system - the CNC administrator needs to be in CHARGE of all objects - not delegate the responsibility to a save location.

[ QUOTE ]

4. Full builds are more reliable in build and deployment.


[/ QUOTE ]
In the respect that a full package catalogs the entire source tree - this is a correct statement. Probably the only truthful statement in this post.
[ QUOTE ]

5. No more concerns about recompressing parent packages
-or- not compressing the parent package. Or, whether compression works with update builds.


[/ QUOTE ]
I never recompress parent packages - just because you do update packages, doesn't necessitate a recompress - you just need a script to go through and silently install each update one at a time.

[ QUOTE ]

6. Full packages are a snapshot in time, updates aren't.


[/ QUOTE ]

Full packages are a snapshot in time of the entire tree. updates are a snapshot in time of a smaller number of objects. If you're going to quote the CNC and Architecture guide, do it right.

[ QUOTE ]

7. In 8.12, there isn't any serialized object generation. Its part of the builds so generation is not an issue.


[/ QUOTE ]
We're not talking 8.12 - we're talking Xe and ERP 8.0. Not sure why this point is being made

[ QUOTE ]

8. Properly configured deployment servers can do a full build in 4 hours. For an update build, I spend 1 hour on the build and 3 hours explaining change control, CNC, development tools and package builds to semi-trained developers and project managers. The amount of time is a wash.


[/ QUOTE ]
Properly configured deployment servers in Xe can do a full build in an hour for a pathcode. However, an update package can take as little as 5 minutes to process. I really don't mind teaching and explaining to developers and project managers about how CNC works - after all, thats my job - but it seems to you that informing others about how the system operates is a waste of time.

[ QUOTE ]
9. Hardware (network and servers) to support package build processing is becoming much cheaper than the lost productivity caused by the eight items above.


[/ QUOTE ]
It seems to me that you have set yourself up to be easily replaced too - after all, if you're not teaching CNC nor are you managing your implementation - what ARE you doing in your organization ? I think your productivity can easily be replaced by a clockwork orange...

[ QUOTE ]

10. Package builds are a non-value add process, boring and I hate wasting time on them.


[/ QUOTE ]
Package builds are an important part of any development environment. Its just that usually, the process is called "source control" and "compiling". Anyone with an ounce of intelligence and enough experience to fill a gnats testicle should be able to understand that and relate what, to you, is a boring task and what is to everyone else a necessary part of their administrative role.

I would suggest that you look outside of JDE for YOUR next role - because it seems to me you have no idea of how to correctly manage a centrally located development environment - and your answers pretty much tell me you are a danger to your corporate IT environment.

[ QUOTE ]

If you look at the history of CNC, Oracle's design is beginning to de-emphasize update builds anyway. Fat clients are gone. Developer's can test everything (web, reports, etc.) without a full build on the server using their development workstation.

[/ QUOTE ]

Fat clients are NOT gone as far as Xe is concerned. Xe is going to be supported until 2013 - and ERP8.0 and Xe combined make up a pretty big market share of JDE installbase. Today, Web and reports are a nightmare performance issue under 8.9x and you need BIG box to run these functions. This has been a nightmare for years - and as I stated before, anyone who had the slightest investment in eliminating the terminal servers should have been wiped from the planet long ago - after all, they no longer work for JDE and we have to deal with their crap. But we cant change what has occurred. But sometimes its interesting to point out jerkoffs that post crap on here when they obviously understand nothing, and have "no time" to help their co-workers.

Hope you get creamed....

---------------------The MaDXeHAXXER