Most Windchill still runs on-premise
Export control, an ERP next door, a datacentre that was paid for last year: there are good reasons not to move Windchill to the cloud, and we do not treat them as problems to be argued away. CI/CD is not a cloud feature. The discipline behind it, that every change is built from source, tested on an environment that matches production, and reversible by a job that has actually run, applies exactly the same on a vSphere cluster as on Azure Kubernetes.
What differs is the last step. So we build the pipeline once and give it two ways to land.
One build, two delivery paths
Every change follows the same path, whether it is a PTC release, a CPS, or one of your customizations:
- Build. Customization packages are compiled from source with the Windchill Ant build on every commit. The output is a versioned artefact, identical for both targets.
- Deploy to test. The artefact is installed on a test environment that mirrors production, by the same job that will later touch production.
- Verify. Automated smoke tests exercise search, check-in, change creation and the integrations you depend on.
- Promote. The tested artefact, not a rebuild, goes to production. Rollback is a job in the same pipeline.
On-premise
- Self-hosted agents inside your network. Source and artefacts never leave it. Your Git can be GitLab, Bitbucket or Azure DevOps Server; the pipeline does not care.
- No outbound internet required. Maven, npm and image dependencies come from an internal Nexus or Artifactory and a registry mirror, so a build is reproducible even when the firewall is closed.
- Deployment with Ansible against your existing servers. Artefacts are staged, property changes applied through
xconfmanager, load files applied idempotently, and method servers restarted in rotation behind the web server so users are not dropped mid-session. - Honest maintenance windows. Where a release genuinely needs a full stop, you get a scripted runbook rehearsed against a clone and timed, instead of an estimate.
- Rollback that exists. The deploy job takes a codebase snapshot and a database restore point before it changes anything, and the restore path is tested on every release to test.
- Air-gapped sites. Signed artefact bundles move through your controlled transfer process and are verified on the way in.
Cloud, on Azure
- Container images for method servers, background servers and Solr, built by the same pipeline.
- Helm and helmfile onto AKS, with vaults on Azure Files, the database on a managed service and secrets in Key Vault, all described as infrastructure as code in your repository.
- Rolling method-server updates and traffic switching for zero-downtime releases where the Windchill version allows it.
- Environment cloning so test and training can be refreshed from production in hours rather than over a weekend.
Hybrid is the normal case
Most estates we work with are not purely one or the other. Git and the build run in GitHub or Azure DevOps while self-hosted runners deploy into the datacentre. Test and training environments sit in Azure while production stays on-premise. During a migration both targets are live at once, which is precisely when having a single pipeline stops being a nicety.
Building the pipeline first is also the cheapest way to prepare a move. Once releases are automated and rehearsed, changing where they land is a configuration change rather than a project.
Observability, either way
Dashboards and alerts for method servers, queues, vault storage and database health, wired to whatever you already use: Azure Monitor, Prometheus and Grafana, or your existing on-premise monitoring. Backups and their restores are tested on a schedule, not assumed.
Where it runs and who owns it
Your subscription or your datacentre, your accounts, your data. We build and operate the environment; you own it and can take it over at any time. Handover is part of the work, not a separate phase: runbooks, infrastructure as code and a walkthrough with the people who will be on call.