Hello Houssem,
I prefer doing ThingWorx DevOps externally, without installing ThingWorx extensions. The underlying logic -- we already have decent Git clients and tooling for mainstream web development, why not use it for ThingWorx? Our typical approach is to create individual ThingWorx sandboxes, one per developer, using Docker, k8s, EC2, -- depending on what your IT provides. Then we create a simple shell script (export.sh), which exports remote ThingWorx entities from developer's sandbox as XML files to their local machine. Developers then manage those XML files using their familiar Git client just like any other sources. To get latest changes, they do git pull and then deploy the local workspace with XMLs via another shell script (deploy.sh). We made https://github.com/vilia-fr/twx-cli to simplify this scripting.
CI/CD works similarly, using the same deploy.sh script. The crucial difference is that for deploying to the developer's sandbox you should use "Import Source Controlled Entities" (so that you can modify them), while for deploying to a prod-like server your should package your entities in an immutable extension instead -- this way you'd be able to deploy new versions atomically and refactor your code without leaving old garbage on the server. On a real project deploy.sh typically contains about a dozen of steps -- importing extensions, sources, translations, configuring stuff... -- that's the core of our CI/CD pipeline basically.
Other important aspects to consider:
- Unit tests and e2e tests, e.g. twx-unit
- Configuring the environments after you deploy the entities. Here you'd need to make some important decisions about the lifecycle of your configuration -- what part of it you want to store (and deploy) together with the source code, and what part will be more dynamic. Merging configuration changes into what is already in the system is one of the most non-trivial CI/CD aspects, which is often underestimated.
Shameless plug -- my company have been doing DevOps and ThingWorx CI/CD consulting since 2017, it's our bread and butter 🙂 We went live with 12 projects following the approach I described above. DM me if you'd like to discuss it in more detail.
/ Constantine
