Survey: What is your process for deploying Windchill changes to your Production system?

[jfrankovich]

All:

We are wondering how different companies deploy the configuration changes and customizations that they have made in a test environment into their actual production system. We, the Windchill team (a branch of Engineering Services), currently implement and test changes in our development environment and then we deploy them on the production system. Our IT department wants the production deployment to be handled by someone other than those that deployed the changes on the development system - similar to the way it is done with our ERP/financial systems.
Just looking for how others handle this.

Thanks,
John Frankovich
GSI Group LLC
www.gsiag.com<">http://www.gsiag.com>

[tbusch]

I've been working on this, I've got an ant script set up that handles roughly half of the steps of deploying a customization. It checks everything out from source control, deploys custom & third party .jar libraries, I*E tasks, resource bundles (roles, lifecycle states), custom JSPs and navigation actions. I'm hoping to add workflows, lifecycles, etc. to the mix before long.

The idea is to make it "braindead simple" to deploy to production after everything is tested on the QA system, so that a non-developer can do it without trouble. This would allow for proper segregation of duties.

Prior to this approach, I would actually document all of the steps I took to deploy to the QA environment. That documentation would serve as a checklist or script for the production release.

-Thomas R. Busch
Sr. Software Developer
Stryker Instruments
(269) 323-7700 x4014
tom.busch@stryker.com<">mailto:tom.busch@stryker.com>

[AL_ANDERSON]

We have a different production support group who promotes changes and
maintains production completely separate from our development group that
builds and tests changes.

We have actually outsourced our production support for our enterprise
applications, including our Windchill products, and our ERP systems. Our
development groups are a mix of in-house IT people, consultants,
contractors, etc. Once development completes a change for production,
they package it, have "Enterprise Business Process Team" representatives
test it, then development passes it off to production support who test it
themselves on a QA environment, then schedule a production change with our
IT change board. We have our EBP group write the end user communication
about the upcoming change, and they also update any training or support
material that has to adjust based on the change.

There are some exceptions to this process, however. Some simple
administrative changes (i.e. add a pick to an existing resource bundle,
for example) can be done on a service request directly by production
support with EBP approval. In that case, production support gets the
approval, tests in on QA, schedules the production change, and then makes
the change as scheduled. Again, EBP is responsible for communications and
any training material updates.

Al Anderson
Solar Turbines Incorporated





John Frankovich <->
11/30/2010 08:51 AM
Please respond to
John Frankovich <->


To
"-" <->
cc

Subject
[solutions] - Survey: What is your process for deploying Windchill changes
to your Production system?




Caterpillar: Confidential Green Retain Until: 12/30/2010



All:

We are wondering how different companies deploy the configuration changes
and customizations that they have made in a test environment into their
actual production system. We, the Windchill team (a branch of Engineering
Services), currently implement and test changes in our development
environment and then we deploy them on the production system. Our IT
department wants the production deployment to be handled by someone other
than those that deployed the changes on the development system ? similar
to the way it is done with our ERP/financial systems.
Just looking for how others handle this.

Thanks,
John Frankovich
GSI Group LLC
www.gsiag.com


Site Links: View post online View mailing list online Send new post
via email Unsubscribe from this mailing list Manage your subscription
Use of this email content is governed by the terms of service at:

[Cosmo]

Hi John,
We're a relatively small company with about 1,000 employees. We don't have a true "team" to do any testing/updating and certainly not two distinct groups of people.
Up until recently, we only had a production system that we did everything on (not recommended). We recently (within last six months) were able to get a test server up and running. The test server is a rehosted version of our production system so they are identical implementations.
Currently, our process is to:
1) first create/develop the new functionality on our test server.
2) If the functionality looks usable and ready to implement, we create a back up of our test server.
3) then we reload the test server with a new dump file from our production server to create a new clean test environment.
4) we run through the steps to implement our new functionality on the test server again to make sure we didn't miss anything. If we did miss something, we can alway reload our test server from the backup we created of it in step 2.
5) once we have the procedure correct on implementing the new functionality into our test server, we then go through the same procedure on our production system.
Ideally, we'd have a third system (which I believe PTC recommends) so that we would not have to wipe our test server clean to re-implement on it. In the recommended scenario, we'd have a development system to mess around on and develop our new functionality, a test system (identical to the production system) to implement new functionality on and test just prior to implementation, and then the production system itself.

Mike -

[achukwuka]

John,

We use a similar procedure to what Al X. Anderson discussed in his response. We have an ant script that checks out all the source code from our source control system(Starteam) including .java files, I*E tasks and etc, compiles the .java files to generate the .class and bundles them into a .jar file which we then unpack onto the windchill system. We normally backup the current Windchill folder just in case a rollback is required. If you use I*E tasks, make sure to delete the compiledTask directory so that the updates made to I*E tasks are recompiled and reached.

HTH,

Alexius C. Chukwuka
JDPS Division SAP BASIS Team
John Deere Power Systems

[achukwuka]

Sorry, I meant the procedure mentioned by Tom Busch.

Alexius C. Chukwuka
JDPS Division SAP BASIS Team
John Deere Power Systems

[MikeLockwood]

Sounds like a lot of overhead and effort with little value.

We have a small group that sits close to each other and just coordinates closely. We do all development, testing, documentation, installation, follow-up, user support, etc. for the extended Windchill system (including Pro/E, MathCAD, etc.) with very little formality.

We do prepare careful "deployment instructions" for more complex changes, and attempt to have at least one other person execute them when possible.

[tbusch]

I was directed by another user to this excellent presentation from PTC/User 2010 (which I was unable to attend):


From: Lockwood,Mike,IRVINE,R&D [

[ddemay]

If changes include a lot of customization, you need to omit the possibility of human error through automation.

Even the best documentation in a software engineering sense doesn't solve problem entirely.

But then again that is only an issue if you are in fact doing a lot of customization with java code; etc.

I can speak more to this once you clarify "changes" as configuration or a blend with major customization.


David DeMay


Sent from my Verizon Wireless BlackBerry