Can we Build packages from DEP environment?

Can we build packages from the DEP environment on the Deployment Server. I know we can deploy from that environment but my question is can we build packages for e.g. PY, DV and PD packages after logging to the DEP Environment on the Deployment Server?

Technically we should be able to do that.

Please let me know

Thanks
CNC Guy
OneWorld XE/8.0 SP19
NT

That is the only environment you should build packages in on the deployment server. However on a fat client you should log into the environment you are building the package for.

CNC guy

Yes you can. As a practice, that is the only place that I do my package builds from.

Praxair CNCguy

It looks like you've got as many opinions as responders. Here's another. We always build our packages on a Developer's workstation in the Development environment. That includes packages for the Production and Prototype environments. We have been doing it for seven years without a problem, that is, without a problem because of where we were building the package.

Here's my two cents worth,

I guess I'm the only one that has had issues building in DEP. Because we
never deploy packages to our deployment server we have not been able to
build UPDATE packages from the DEP environment because the various custom
versions were simply not there. When we add the Reports or Applications to
the package and try to prompt for versions to build, the custom versions
were not in the list. By signing on to a fat client in the environment we
are building for, the versions were there.

So, as a rule of thumb we follow:

- Full package builds - Fat client any environment OR deployment server
DEP environment.
- Update Packages - ONLY from Fat clients signed into the environment we
are building for so we can find the versions.

Regards,
Gerald

You can build full packages for any environment logged into any environment on any workstation that has development objects and C++ installed, this includes the deployment server (except being logged into the planner environment).

For update packages you need to be a bit more careful. You need to be logged into a workstation in the environment that you are defining the package for. This is because the system will look for versions mentioned in your package in the F983051 that is mapped for the environment that you are logged into and not the one that you say you are defining for.

Once you have defined the package you can build it from the deployment server, deployment environment if you want, BUT I would always stay on the workstation where I defined the package in the environment that I defioned it for (as long as it has development objects and C++).

I have alway signed onto the dpeloyment server into the Dep env to build
either a Full or Update package. I have never encountered an issue.
Barb Kramarski

Just as a point of reference, when you check in a version, it checks into your active environment and into the Development environment, making it available to promote to other environments. Unless it is promoted, it will never exist in the other environments.

You can build a package from the DEP environment on the Deployment Server OR from another machine logged into the environment in which you wish to build.

However, there are things to consider:
If you are building a package that contains VERSIONS (especially custom versions), you should ASSEMBLE the package from a fat client logged into the environment in which you are building. This is because the Deployment Server will not pick up the custom versions as they do not exist in the F983051 that the Deployment Server looks at when you assemble the package.

Take also into consideration a package containing a version in the DV environment. If I log into PY and access OMW, it will say that the Version Does Not Exist because that version is not in PY. So if I attempt to assemble a package for DV containing this version and I am signed into PY to assemble it, the version will not be found and will not get built.

The custom versions will only show up in the environment in which they exist. This is also why you can't assemble a package with custom versions in the DEP environment. The custom versions don't exist there.

The only caveat is that you can assemble and build a full package in any environment for any environment because the system knows to automatically pick up ALL Versions for that environment regardless of whether they exist in the environment in which you are logged into.

Hope that helps a little.

Shawn is on the money. We used to try building all packages on the deployment server. (but) Update packages with custom versions will not build correctly unless the package is created on the development client where the versions were created. Now we create the update package on the fat client first, then submit the build on the deployment server.

Remember what I said earlier about opinions. When they are so varied, think about their before and after cost.

This one is free.

I feel so vindicated.

Regards,
Gerald

I'll add in a few more pennys to the conversation. As a practice, I generally build full packages. In my shop, I have a multitude of developers from several countries, so it is easier for us to build full packages rather than bug all of the developers for all of their changes.

That being said, if we have a hot issue that needs an update package, I still build it on the deployment server. When I select individual items, I click on the "all versions" box. This gets me around the gotcha that Shawn described.

Gregg, the Buffalo NY CNC guy

Are you sure this is the case? It should only build from the F983051 that you are mapped to on sign on or else go straight to the Planner and only build XJDE and ZJDE Versions.

Yeah...I wish I can do that at my place of employment....it is so time consuming, but when we build and update package here I have to select only the individual versions that have been changed, and we are talking for a list sometimes of over 100 versions attached to a single UBE. And that is not the worst part; sometimes our developers have these versions in multiple projects. So there I think I am done with R76XXXX|XXXXXX in project A only to find R76XXXX|XXXXA in project B, sometimes it take me over an hour to do an update package, so I have made it a rule that if it is going to take more than an hour then A full package will be done

As for where I build these package I always do full packages on the Deployment server as for updates mostly on my workstation or I will assemble them on my PC and then build on the Deployment server, so far I have not had any issues with doing it that way....my gripe is with the not being able to select all versions in an update for any environment.

[ QUOTE ]
Are you sure this is the case? It should only build from the F983051 that you are mapped to on sign on or else go straight to the Planner and only build XJDE and ZJDE Versions.

[/ QUOTE ]

Hi Shawn,

yes I am quite sure. I've done this process (build an update, select an object, choose all versions) at least 50 times without an issue. Updates are not a huge issue here since I build and deploy a full PY package weekly. I build and deploy a full PD package three times a month (I skip the weekend prior to closing).

Gregg, the package building maven

Hi Cleo!

Nice to see you jump in on the conversation. Who knew this would be such a lively topic? You make my case. If it takes the CNC an hour or so to create the package definition, and yet things can still be missed, creating a need for another update package, then you really should consider building a full package. If that is a big no-no, then follow my suggestion and select "all versions." Yea, sure, you'll recompile an object that didn't change. but isn't that better than not compiling it in the first place? Hmm, that sounds like a geekafied adage....

Gregg, the Package Pundent

Wouldn't it be nice if we could train our developers with a little more
consideration for CNC.

One thing I try to implement where there is a lot of development and
multiple developers is a single Daily Build project. Sometimes just called
DAILYyymmdd depending on how long it takes to get promoted through the
environments.

- Create one project (ie. Daily060308) and grant the developers access at
status 21.
- if any or all developers want something built, they move the object in
there.
- at 15:30 (or whatever makes sense) I promote this project to a status he
developers have no access to ... say 23. OMW security locks them out.
- I can check the objects out and back in again to verify they are ok.
- I build and promote from ONE project. If the developers miss the
deadline... they wait until tomorrow. And by checking out the project and
checking it back in again, the project objects show up in the package
assembly under that project. I can also use the Project Objects UBE to get
a list of all the objects that I can file for future reference.

One Project, one build, one deployment. And the project can be promoted as
testing and acceptance occurs.

This method can be done daily, twice a week, whatever you need. The point
is you don't have to go hunting for what objects to build or wonder if you
missed anything. The responsibility for that is with the development team.

I have used variations on this theme but it seems to work fairly well.

Regards,
Gerald

Gerald,

I think you misunderstand the reason why the are called OMW PROJECTS. Most development is based on a Project Basis. If you are suggesting that a developer move objects out of a PROJECT and place them in ‘the black whole’ – then I’ll try to add just a tad bit of clarity – from a Developer’s point of view.

The developer is assigned a task. They create a PROJECT to keep all the objects necessary for that ‘assigned’ task – and they maintain all the objects for that task in that project. They promote the PROJECT because it maintains all the relationships to complete the assignment – in one ORGANIZED area.

The developer then promotes their Project to a status (something safe, like you said – 23). The CNC should monitory all projects at this status – and consider them, once they hit 23, to be OK for a PY build (your setup may vary).

At an assigned time during the day – the CNC will promote every PROJECT at a status 23 to a Status 26, then start the build process. The Developers should not be allowed (either by rule or agreement) to demote from a 26 to 21 until after the build process… it’s the client’s decision….

Now – if the objects actually get tested (  ) – one or more of them may fail the success test. That said – the entire project (the Developer’s One Project with All Their Goop) get’s rolled back….

Rolling back that one Project – is a lot friendlier than kicking objects in/out of a black-whole project…. The name of the game is ownership, control and COMMUNICATION…. If a black hole project is used – then what happens when an object (a single object) needs to be rolled back – and 75 of the other objects are fast-tracked to Production?

To cut short – here’s a better solution… or at least a better solution I’ve experienced at some of the sites I’ve worked at.

(db)’s Suggested Solution:

Every Developer (or SME) that will be doing Projects is assigned a ‘COPY-THIS’ project (you can name it whatever you want). Within that project are all the PVC Admins, CNC Groups and any other Owners that may ever need to be tied to the project. When the developer is assigned a new task – they COPY the ‘COPY-THIS’ project to ‘whatever’ they are going to call the new project.

When they are ready to have it built – they promote to a Status 23, and the CNC’s pick it up at the pre-defined time. Since all the CNC/PVC folks are already ‘owners of the project – they don’t have to go looking for it (just monitor Status 23).

I’m sure there are loopholes to the process that we can all dream up – but, I can tell you that the process works solidly at several organizations.

(db)

Hi Daniel,

I've worked in that flavour as well. The bottom line is as long as you can
establish a working process before the project gets under way and the
customer understands the overhead required by the CNC's for the various
methods, then we can all get along.

Regards,
Gerald





DBohner
<[email protected]
om> To
Sent by: [email protected]
jdelist-bounces@j cc
delist.com
Subject
Re: Can we Build packages from DEP
03/08/2006 04:38 environment?
PM


Please respond to
JD Edwards®
EnterpriseOne






Gerald,

I think you misunderstand the reason why the are called OMW PROJECTS. Most
development is based on a Project Basis. If you are suggesting that a
developer move objects out of a PROJECT and place them in ?the black whole?
? then I?ll try to add just a tad bit of clarity ? from a Developer?s point
of view.

The developer is assigned a task. They create a PROJECT to keep all the
objects necessary for that ?assigned? task ? and they maintain all the
objects for that task in that project. They promote the PROJECT because it
maintains all the relationships to complete the assignment ? in one
ORGANIZED area.

The developer then promotes their Project to a status (something safe, like
you said ? 23). The CNC should monitory all projects at this status ? and
consider them, once they hit 23, to be OK for a PY build (your setup may
vary).

At an assigned time during the day ? the CNC will promote every PROJECT at
a status 23! to a Status 26, then start the build process. The Developers
should not be allowed (either by rule or agreement) to demote from a 26 to
21 until after the build process? it?s the client?s decision?.

Now ? if the objects actually get tested (  ) ? one or more of them
may fail the success test. That said ? the entire project (the Developer?s
One Project with All Their Goop) get?s rolled back?.

Rolling back that one Project ? is a lot friendlier than kicking objects
in/out of a black-whole project?. The name of the game is ownership,
control and COMMUNICATION?. If a black hole project is used ? then what
happens when an object (a single object) needs to be rolled back ? and 75
of the other objects are fast-tracked to Production?

To cut short ? here?s a better solution? or at least a better solution I?ve
experienced at some of the sites I?ve worked at.

(db)?s Suggested Solution:

Every Developer (or SME) tha! t will be doing Projects is assigned a
?COPY-THIS? project (yo! u can na me it whatever you want). Within that
project are all the PVC Admins, CNC Groups and any other Owners that may
ever need to be tied to the project. When the developer is assigned a new
task ? they COPY the ?COPY-THIS? project to ?whatever? they are going to
call the new project.

When they are ready to have it built ? they promote to a Status 23, and the
CNC?s pick it up at the pre-defined time. Since all the CNC/PVC folks are
already ?owners of the project ? they don?t have to go looking for it (just
monitor Status 23).

I?m sure there are loopholes to the process that we can all dream up ? but,
I can tell you that the process works solidly at several organizations.

(db)


Member - iConsortium Always looking for new gigs! Daniel Bohner | JDE
Developer Independant-JDE/Web/Photo www.ExistingLight.Net |
[email protected] JDE XE - 8.10 | AS/400