Package Builds / Deploy Numbers

I am trying to find out what other customers are doing for their package build / deploy schedules. I am wondering how many, what times and anything else that you can throw out here would be great!! Here is what we are doing:

Monday 11:30 AM Builds for DV and PY Deploy, at 12:30 PM
Tuesday 11:30 AM Builds for DV and PY Deploy, at 12:30 PM
Tuesday 3:30PM Builds for PD and Deploy at 9:00 PM
Wednesday 11:30 AM Builds for DV and PY, Deploy at 12:30 PM
Thursday 11:30 AM Builds for DV and PY, Deploy at 12:30 PM
Thrusday 3:30PM Builds for PD and Deploy at 9:00 PM
Friday 11:30 AM Builds for DV and PY, Deploy at 12:30 PM

This is often times not followed, we are building more then scheduled. This is after we have gone live (March 2004) and is just production support. Breakdown of number of packages per month since I have been keeping track:

MAY 76 Packages
June 49 Packages
July 50 Packages
Aug 29 Packages (So far)

This is a five day build schedule nothing on weekends except for Full packages. Before we went live we were building double this so close to 75 to 100 packages a week and supporting another pathcode.

With that you can see we are building over an average of two packages a day.

I am looking for any and all input you can give me, like pre-go live and post-go live. What you think works for a schedule, anything that could help me with this.

We run EnterpriseOne, iSeries V5R1, Citrix Metaframe FR3 Service Pack 22_W1.

Thanks!

Nick

I must assume these are all update packages.
How often do you do full packages?
I thought my updates were excessive.
How about object count? Mine typically run at around 100 objects.

We are Global and have been live since June, our schedule looks like this:

Monday - 1 update for each environment DV9, QA9 and PY9
The request cutoff time is 12Noon
The deployment time is 5:30pm

Wednesday - 1 update for each environment DV9, QA9 and PY9
The request cutoff time is 12Noon
The deployment time is 5:30pm

Friday - 1 update for the PD9 environment
The request cutoff time is Thursday 5:00pm
The requests are reviewed and approved on Friday 9:30am
The deployment time is 8:30pm

Nick,

Wow! That is a lot of package building. We historically have tried to build a new full package (for each environment) every three months, and try to schedule update packages once every two weeks.
Of course, if we have a hot fix, we'll do updates as needed.

I'd be a bit concerned about so many update packages, given what our environment is like. How many developers do you have, and are all these changes being tested before deployment? And is deploying them so soon really necessary, or can you wait and batch them, say on a weekly or so basis? I'm not trying to tell you how to run your operations, just a suggestion that might ease your package build burden.

As far as pre- and post-go-live, we tend to have a flurry of changes right after go-live, and then within a month or two, things usually settle down, and we're back to our normal schedule.

For package build times, each of our current OneWorld XE full packages take about 11 hours to build. On our new EnterpriseOne 8.9 system, each full package takes about 4 hours to build.

Also, we don't use compression in our packages, so we don't have to recompress parent packages after doing update packages; our network bandwidth is enough to accomodate this approach.

Thanks for the posts so far!!!

I'll help answer some questions:

These are all update packages.
We don't have a schedule for Full packages.
The object count is small usually 20 sometimes 50 sometimes 5.
We have about Three maybe four developers making changes. The majority of it all comes from two.
As far as testing I personally feel they are not being tested, I get this because we sometimes build the same package 3 or four times in one week. Lots of times where we build it at noon then build it again at 3:30.

And thank you for the deployment question I am told they need to be deployed that quickly, but I don't know.

Also we have lots of days where something goes to DV-PY-PD all in the same day. Any thoughts on this?

Nick,

Sounds like your developers/analysts are out of control. Some discipline needs to be applied here.

Just my opinion.

This is the type of feedback I am looking for.

How about your package build / deploy schedule?

Nick

When we first went live, we built update packages (for all environments) twice per week (sometimes more). As time went on, we reduced update package builds (for all environments) to once per week. Now we build update packages for all environments every other week, and DV only packages weekly.

For us, the best schedule is to build packages on Tuesday afternoons (everything needs to be checked in by 1:00) and deploy on Tuesday evenings (because we can't deploy to the terminal servers when they're in use).

Although less rigorous testing is common right after go-live, I recommend you break your developers of this habit ASAP. Untested mods and custom UBEs and applications in production can cause you far more grief than not having the mods or custom objects.

I work with DSAUVE - see his reply.

Wow that is a lot of packages! I build a Full production package once a month, other environments get a full package after about 10 update packages. I probably build about a dozen packages per month tops. However I am the only one doing development here.

Are you taking your prod system offline when you deploy your updates?

Sorry to intrude, I just wanted to mention briefly that there's a way to "hot deploy" software updates to Terminal/Citrix Servers as well as Fat Clients, even as the users are using them - we sell a software tool for that.

If you would like more details, please, e-mail me directly.

Hi,

Just want to share how package builds are done in our site. We do full package for PD once a month. Update pak almost nil depending on if we need to deploy new objects in ES. For report version, instead of creating new update package, I just jiti them in citrix servers even users are on-line. We have been using this since we've gone live in 2001. I agree to all who responded to your topic. There should be a methodology to be followed in all developments/customizations activities to ensure control and integrity of the system. At the very least follow the standard procedure recommended in the jde manual. Thanks.

Hi all,

We have been live since November 2003, and went live with a new module 1
Jul 2004, we are still have two developers working on priority 2
reports. We build a full package for Production once a week (over the
weekend), and typically a Full package in our unit test environment
about every second day. In an emergency we will build a production
package overnight during the week. Before implementation, we were
building Test packages every night, sometimes in two environments, and
Production packages about every second day.

I prefer to build Full packages rather than update packages, because
sometimes update packages don't quite work properly. I really avoid them
in Production, unless it's a real emergency, but for testing I'm happy
to build update packages during the day (as required by developers, who
understand the issues).

It takes us about 4.5 hours to build a full package. For Production it
takes about 4 hours to deploy the package to our 16 Citrix servers (the
way we do it). For development/testing, we have only one Citrix server,
and if needed we can kick the developers and testers off during working
hours for deployment. (Normally we don't, though).

The developers and testers know their changes will be available for
testing the next day, and the business is coming to know they can have
changes to Production made each weekend, ready for Monday. Exceptions
are made, though.

The schedules above mean we do some of the work evenings and weekends,
using remote access. It's the best way of implementing changes without
impacting on Production availability. In practice our business is
operational for 14 hours a day, so there is plenty of opportunity to
work in the background.

Regards,
Mark

ERP8, Update 1, SP22_S1, Windows 2000 (Server and Advanced), SQL Server
2000, Citrix Metaframe XP


######################################################################### ############
Note:
This message is for the named person's use only. It may contain confiden tial,
proprietary or legally privileged information. No confidentiality or pri vilege
is waived or lost by any mistransmission. If you receive this message in =20error,
please immediately delete it and all copies of it from your system, destr oy any
hard copies of it and notify the sender. You must not, directly or indir ectly,
use, disclose, distribute, print, or copy any part of this message if you =20are not
the intended recipient. Stockland and any of its subsidiaries each reserv e
the right to monitor all e-mail communications through its networks.

Any views expressed in this message are those of the individual sender, e xcept where
the message states otherwise and the sender is authorized to state them t o be the
views of any such entity.

Thank You.
######################################################################### ############

More question answering:

Yes we are taking the system offline to deploy packages.

Yes I would love to hear more about online package deploys.

I want to say thanks so far everyone for posting, please keep it up!!! Thanks so much everyone.

Nick

Re: RE: Package Builds / Deploy Numbers

So you Only build Full packages? How many do you keep, as far as versions back?

Nick

Re: RE: Package Builds / Deploy Numbers

Ok - on my website there are two whitepapers you might like to check out, specifically for larger development customers.

I have certainly been involved with customers with at least this amount of development - and no, the developers are not always out of control - in VERY large implementations, there might be thousands of modifications - especially when the customer decides to completely write an application from scratch.

Hence, good package methodology is required - and these documents help with naming conventions, package implementations etc etc.

My guess (and hope) is that you're running Citrix - if you've got Web involved, then that'll mean an extra step with the JAS generation, which is a real pain (I've had that involvement too in large development environmens many times).

Anyway, read through the whitepapers and see if they help :

1. "OneWorld Xe ESU Update Procedures" - this contains naming conventions, everything to do with package builds, even though the ESU procedures might not help.

2. "Revised ESU Upgrade Procedures - the Case for QA" - this takes the procedures a step further for very large development companies, and helps customers understand the "4th pathcode" or Quality Assurance Testing pathcode.

All these can be found at http://www.erpsourcing.com

Re: RE: Package Builds / Deploy Numbers

What do you think is a large development project?

What we have:

We have gone live now with about 250 users, we have 2 developers that do most of the work, and another 4 that do some work. We don't have a lot of modifications except for P4210. We run finanicals and distrubution only.

Thanks!

Nick

Re: RE: Package Builds / Deploy Numbers

The answer, unfortunately, is "it depends" !

One customer in Florida that I was associated with had created more than 2,500 custom objects over the time of their implementation - most of these were of course reports - but they had pretty much redeveloped the entire Purchasing module, and had made modifications to business functions including B4200310 - that was certainly the most modified customer I've been associated with. At the peak, they had approximately 20 developers, I believe they're down to around a dozen or less right now - but they are very stable and have more than 1,000 concurrent users.

Another project I was involved with last year had almost 40 developers - most of which were based in India on an outsourcing deal. After the go-live they reduced dramatically to around 10 developers or so. That customer was building around 100 packages in development per month at their peak, again, a very large development effort.

If you're making a large number of modifications to business functions and/or forms/batch processes, then I'd expect a customer would really need excellent quality assurance when it comes to pre-production testing. PY doesn't really do this, since its aimed specifically at testing the modifications that you're working on. QA does a much better job, if implemented correctly, of retro-actively testing other parts of the functionality that might be affected prior to go-live. The second document talks about that.

However, every customer I've worked with usually accepts the first document as a basis for their development methodology. It works well, and it works very much in-line with the standard JDE activity rules. There is always contention about how ESU's should be implemented - but treat the document as a "best practice" when it comes to this. Even smaller development shops benefit greatly from documented procedures when it comes to development and promotion.

Re: RE: Package Builds / Deploy Numbers

altquark I have a couple questions since you seem to know a lot about what other customers are doing. (Or anyone else who would like to join in please do so)

1) Could you give a few examples of what other customers do?

2) How do you feel about projects going up multiple times a day, meaning a project built for DV at 11:30AM getting bulit for DV again at 3:30PM?

3) What about projects gettign built for multiple pathcodes all at the same time or same day? Meaning something built for DV and PY at the same time? Or sometimes DV and PY and PD all in the same day?

We are live. We have been live with financials for close to two years and live with distrabution since 4/04. We do not have a large number of mods. We have about five developers but two really do all the work for JDE, it is mostly UBE's. We do have Trax, Optio, RFSmart.

Thanks in advance,

Nick

RE: RE: Package Builds / Deploy Numbers

I notice from the conversation that some people build a lot of update
packages, and it sounds like they build these mostly in DV and sometimes
in other environments. Sometimes multiple builds in DV each day, often
for UBEs.

I'm guessing that this is so people can test the UBEs, and the UBEs run
on the batch server. However, for the developers, you could set an OCM
mapping so that all UBEs in the DV environment for those users run
LOCAL, not on the server. Then, the developers can do their development
and test the report whenever they want, because everything needed to run
the report is present on their client (whether it be a fat client or
Citrix).

If other people require to test the same newly developed reports, give
them the same mapping to run UBEs LOCAL in DV, and teach them to do a
Get on OMW on all the objects required for the report to run. Then, a
lot of the initial testing and refinement can be done without a package
build.

I ought to point out that before we approve mods for promotion to
Production, we do promote the objects to a separate Unit Testing
environment, build a package, and test the reports in a manner as
similar as possible to how they will run in Production.

Another trick we use is to have a separate user available for the
developers which uses Objects and Versions from DV, and Business Data
and Control Tables from the Unit Test environment (this is achieved
through OCM mappings). This enables the reports to be tested in the DV
environment, but using the testing data.

Regards,
Mark

ERP8, Update1, SP22_S1, Windows 2000 (Server and Advanced), SQL Server,
Citrix Metaframe XP



######################################################################### ############
Note:
This message is for the named person's use only. It may contain confiden tial,
proprietary or legally privileged information. No confidentiality or pri vilege
is waived or lost by any mistransmission. If you receive this message in =20error,
please immediately delete it and all copies of it from your system, destr oy any
hard copies of it and notify the sender. You must not, directly or indir ectly,
use, disclose, distribute, print, or copy any part of this message if you =20are not
the intended recipient. Stockland and any of its subsidiaries each reserv e
the right to monitor all e-mail communications through its networks.

Any views expressed in this message are those of the individual sender, e xcept where
the message states otherwise and the sender is authorized to state them t o be the
views of any such entity.

Thank You.
######################################################################### ############

RE: RE: Package Builds / Deploy Numbers

We have three package builds daily. Which can include items from multiple
projects and into multiple environments. We do this mainly so people can
test on the web. Except for deveopers and CNC, all users run on the web
and all testing must be done there. Is there a work around to allow the
developers to do their testing on the web without a package? I understand
this will happen in 8.94 but not now.

Scott W. Allen
EO 8.92_K; Enterprise: AS400, Deploy W2K Server; JAS W2K Server




msuters
<mark.suters@stoc
kland.com.au> To
Sent by: [email protected]
jdelist-bounces@j cc
delist.com
Subject
RE: RE: Package Builds / Deploy
08/26/2004 09:48 Numbers
PM


Please respond to
PeopleSoft®
EnterpriseOne
<jdelist@jdelist.
com>






I notice from the conversation that some people build a lot of update
packages, and it sounds like they build these mostly in DV and sometimes
in other environments. Sometimes multiple builds in DV each day, often
for UBEs.

I'm guessing that this is so people can test the UBEs, and the UBEs run
on the batch server. However, for the developers, you could set an OCM
mapping so that all UBEs in the DV environment for those users run
LOCAL, not on the server. Then, the developers can do their development
and test the report whenever they want, because everything needed to run
the report is present on their client (whether it be a fat client or
Citrix).

If other people require to test the same newly developed reports, give
them the same mapping to run UBEs LOCAL in DV, and teach them to do a
Get on OMW on all the objects required for the report to run. Then, a
lot of the initial testing and refinement can be done without a package
build.

I ought to point out that before we approve mods for promotion to
Production, we do promote the objects to a separate Unit Testing
environment, build a package, and test the reports in a manner as
similar as possible to how they will run in Production.

Another trick we use is to have a separate user available for the
developers which uses Objects and Versions from DV, and Business Data
and Control Tables from the Unit Test environment (this is achieved
through OCM mappings). This enables the reports to be tested in the DV
environment, but using the testing data.

Regards,
Mark

ERP8, Update1, SP22_S1, Windows 2000 (Server and Advanced), SQL Server,
Citrix Metaframe XP



#########################################################################
############
Note:
This message is for the named person's use only. It may contain confiden
tial,
proprietary or legally privileged information. No confidentiality or pri
vilege
is waived or lost by any mistransmission. If you receive this message in
=20error,
please immediately delete it and all copies of it from your system, destr
oy any
hard copies of it and notify the sender. You must not, directly or indir
ectly,
use, disclose, distribute, print, or copy any part of this message if you
=20are not
the intended recipient. Stockland and any of its subsidiaries each reserv e
the right to monitor all e-mail communications through its networks.

Any views expressed in this message are those of the individual sender, e
xcept where
the message states otherwise and the sender is authorized to state them t o
be the
views of any such entity.

Thank You.
#########################################################################
############