Simplified ThingWorx Deployment Setup – How to handle bug fixes efficiently?

Hi @MA8731174 ,

It all stems from your release cadence, acceptance criteria and bug severity labels (note that I don't see STAGING there, which is worrying , since you won't have the guarantee that you'll have a problem-free installation on PROD).

Assuming you have a release cadence of 3 weeks (based on a strong CI/CD chain) you probably will have situations when a breaking Bug manifests during this cycle which makes that release unusable. 

Q1: do you want to manage this situation?

if yes:

Q2: is it acceptable by business to wait until next release cycle?

if not:

Q3: since you need to fix that bug ASAP in the current release, which means you'll need either a temporary environment OR an environment like TEST or QA where you always keep the last version deployed in Prod for such quick fixes (as editable entities since you might need to modify them) . The decision stems from how easy it is to spin up a temporary environment and access rights (we observe in many situations that local dev environments can't be used for such activity because they don't have access to the external systems we're interacting with, and in other cases spinning up resources without approval is not possible because the company does not allow that). Since Dev is unstable, this also means that once fixing that bug in TEST/QA, you'll need to fix it again in Dev (again, assuming Dev is not stable). 

---

👉 Local Instances (Developers) → DEV Environment → Git (Build Pipeline) → Artifact Repository → TEST Server → Production Servers (multiple locations like China, Italy, etc.)

---

I must say that pipeline looks a bit weird. What is the purpose of your DEV Environment, how changes get there and why don't you commit your code to Git from your local instance instead? How do changes get from Test to Prod?..

On my projects I do it differently:

1. Developer implements a change in a personal sandbox, exports it and pushes to Git on a feature branch
2. They open a pull request for the release branch, which acts as a quality gate. The pipeline deploys the PR content on a temporary PR environment, where it can be (re)tested by developer and code reviewer before the PR is merged.
3. Once the PR is merged, the pipeline deploys release branch to the Sprint testing environment, where the rest of the team can test it.
4. At the end of the sprint, if the Sprint Review is successful, the release branch is merged into master, and the pipeline deploys master to preprod, where it will be tested for one more sprint.
5. Once the testing confirms all is good, we tag the master branch, and the pipeline then deploys it to prod (it triggers on tagging).

There are the following environments in this setup:

1. Individual Dev sandbox -- recycled every sprint, deployed approx. once per day
2. Temporary PR environment (optional) -- deployed once and recycled when the PR is merged
3. Sprint Review env -- deployed a few times per day, once per each merged PR
4. Preprod env -- deployed once per sprint (with 1 sprint delay)
5. Prod -- deployed once per sprint (with 2 sprint delays)

The crucial notes:

1. All those environments, including Dev and Prod are deployed using exactly the same shell script (DEV uses Import as Source Control entities though)
2. The deployment is "complete" in the sense that it builds everything, redeploys everything (ALL extensions, ALL code for ALL sub-projects), re-configures everything, etc. -- this ensures that we can rerun it as many times as necessary, and that we can run it against an empty, or existing environment. There's no notion of "short" or "light" deployments, they are all "full", if you see what I mean. It makes life much easier.
3. There are no manual import/export from any of those environments
4. Developers only have access to their dev sandbox Composer
5. PR checklist acts as an implementation of the Definition of Done, and is the most important component in this whole setup
6. Use Semantic Versioning for your tags and extension versions -- this will save you a lot of time

With this setup, hotfixes branch from master, and the PR is opened back to master. Once it is merged, we tag it with another patch version, e.g. "1.0.1", and it gets deployed in the same way as any other deployment to any other environment.

As for the best practices -- read about Git Flow here or here -- it explains exactly how to handle bugfixes and hotfixes. ThingWorx is just a runtime, the process is the same.

/ Constantine