GitHub Integration for ThingWorx - Latest Tools for CI/CD

[HS_12093080]

Hi,

I'm looking for the latest solutions to integrate GitHub with ThingWorx for Continuous Integration (CI) and Continuous Deployment (CD). Specifically, I need to:

• Manage ThingWorx artifacts (e.g., Things, Services, Mashups) in GitHub.
• Automate workflows for pushing/pulling changes between ThingWorx and GitHub.
• Set up CI/CD pipelines using GitHub Actions or other tools.

Has anyone implemented or found an effective way to use GitHub with ThingWorx for these purposes? If so, what tools or extensions are you using?

Thanks in advance!

Houssem

[Rocko]

https://community.ptc.com/t5/forums/searchpage/tab/message?q=thingworx+git

https://github.com/PTCInc/thingworx-gitbackup-extension

[Constantine · Accepted solution]

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

[HS_12093080]

Hello Constantine,

Thank you very much for your detailed response! I really appreciate the insights you’ve shared, and it gives me a lot to think about regarding DevOps and CI/CD for ThingWorx.

I’m very interested in learning more about the approach you’ve outlined, especially with using sandboxes, Git, and the shell scripts for exporting and deploying entities. I would love to dive deeper into the specifics, particularly around setting up the environment, handling configuration changes, and managing CI/CD pipelines effectively.

Would you be open to discussing this further? I would love to learn more from your experience and any best practices you could share.

Looking forward to your response!

Houssem

[Constantine]

Hey, I responded to you in DM.

[slangley]

Hi @HS_12093080 

If you received a satisfactory response to this post, please mark the appropriate one as the Accepted Solution for the benefit of others in the Community.

Regards.

--Sharon