DevOps. It’s not just a buzzword. It’s a true development methodology that can make all the difference in your application quality and release time. Today, I’ll walk you through how you can continuously integrate and deploy your ThingWorx applications to achieve CI/CD objectives as part of a DevOps-focused culture. At the end, I’ll provide you a sneak peek of what you can expect in a future release (hint: we’re working on some awesome new CI/CD functionality).
I’ll start by providing an overview of the DevOps cycle, and then I’ll provide more details around each step of the cycle. Before we can start, you’ll need to define your high-level architecture and functional requirements as part of the “Plan” phase.
Now, let’s build your ThingWorx app. Ready? Here we go!
As with any software platform, developers can start working in any number of areas of the IoT application—from edge, to visualization, rules authoring to data modelling. For the purpose of this article, we’ll start with the UI, but much of the same steps can be applied in any order. Also, we’ll just call out high level steps of development, but for more info on building out each aspect of your application, please visit developer.thingworx.com.
Deploy + Operate + Monitor
There are many different paths through the platform and options for developers to match your local team processes and tools—this was simply a quick overview.
Congrats! You’re now equipped to build ThingWorx apps while leveraging software best practices and incorporating a DevOps culture!
What can I expect in a future release of ThingWorx?
Coming in a near-term release of ThingWorx, we’ll make it easier for you to continuously integrate and deploy your ThingWorx applications. How? Through new functionality that bolsters our packaging concepts, new cloud services to assist in deployment to environments and an error-proof way to integrate applications with an automated dependency awareness.
Stay tuned for more info about this exciting new deployment and application management functionality targeted for Fall 2019!
Reach out with any questions and stay connected.
I was quite interested to find this article, however after reading it I still have a number of unanswered questions.
1) You mention using Composer to Export to Source Control. Can you select to only export updated entities since last export? I know you can do this with services but have not seen it in Composer.
2) You mentioned automated testing with Selenium and JUnit, but there is no mention of anything with ThingWorx. Could you please elaborate on how you would setup automated testing with ThingWorx?
3) You also mention that automation is king, but I don't see anything about automating the Import/Export from ThingWorx. Could you please elaborate on this?
Hi Jeva, Kaya:
When we talk of Selenium, we would do well to also look at robotframework.org.
There is devops related info in these PTC articles:
Source code control is essential for devops:
This backup guide talks on how to export entities for backup but this is also helpful for source code control:
cheers -- Rick
Hi Jeva, Kaya:
You mentioned the “Export to Source Control” feature from ThingWorx Composer. What I would prefer is that the 'Save' button would save to a location in a directory tree that I could use for git or SVN. As it is, it seems that we have a multi-step process:
As an alternative I could export all in Allentities.xml and version this in git, but that is not git-friendly.
(I should mention that TWX Navigate is on a dev server, not on my workstation)
The obvious solution would be for the 'Save' button to save xml to a directory on the server without any need for Export.
thanks -- Rick