A pipeline for Windchill looks like a pipeline for any other enterprise application, with two differences: the application is large and slow to start, and its configuration matters as much as its code. Here is the shape we use and the order in which we build it.
1. Version control for everything
Customizations, build scripts, deployment scripts and as much configuration as can be exported live under version control. Changes are reviewed by a second engineer before they are merged. If it is not under version control, the pipeline cannot deploy it, and that is the point.
2. Build once
The pipeline compiles the customizations from a tagged version and produces one versioned package, for virtual machines or for containers. That package is promoted unchanged from test to production. Rebuilding for each environment is how differences creep in.
3. Test in three layers
- Fast tests for business logic, which run in seconds without a Windchill server.
- Interface tests that call your services on a freshly deployed instance.
- Smoke tests that walk through a handful of critical flows: create a part, check in a document, release a change.
Windchill is slow to start, so we keep the deployed test stage focused. A short suite that runs on every change is worth more than a long one that runs once a month.
4. Promote with a decision
Deployment to production waits for an approval, and the approval is recorded with the release notes the pipeline generated. Auditors like this. So do engineers, because the question of what changed and who agreed is answered in one place.
5. Verify and keep a way back
After deploying, the pipeline checks that the system is healthy and runs the smoke tests again. Rollback redeploys the previous package. We test it regularly, because a rollback that has never run is a hope, not a plan.
Where to start
If releases are manual today, start with stages 1 and 2: version control and an automated build. They remove the most risk for the least effort, and every later stage builds on them.