That certainly simplifies it. You can script out the build process and use variables for the inputs based on the map being deployed, and target environment. TFS might be a lot (to implement / cost) for what is really needed if you're just wanting to manage ITX deployments, however if they are also doing any other custom code (java, c# etc) it can cover all the bases and might make the expense worth it. I can only speak from my experience and I do really like TFS.
In another life I built a free CI system using ANT - and really it could probably be entirely script based even now and you use the repository of your choice.
------------------------------
Lisa Edwards
Software Engineer / Subject Matter Expert
Rainbow Data Systems, Inc
------------------------------
Original Message:
Sent: Tue November 19, 2024 11:00 AM
From: Rex Chan
Subject: Using CI/CD
Thanks for your feedback.
Regarding the container solution, there are 2 containers available in 11.0.1. One is the Rest Server container which has been around since V10. You don't need to restart the container for the new map to take effect.
The other one is the Flow Server container which just came out. I believe it should be the same. I haven't tested it in the container yet but will do soon. In the Design Server environment, it picks up the new map without a restart; however in Windows, the flow server runs as a service.
------------------------------
Rex Chan
Original Message:
Sent: Mon November 18, 2024 02:31 PM
From: Lisa Edwards
Subject: Using CI/CD
While I haven't done it in actuality, I have managed CI/CD systems for transformation systems (based on BizTalk). I really like Team Foundation Server in terms of flexibility and capabilities. The toughest piece of an ITX deploy might be a Launcher restart. I haven't yet worked with Flow Engine to know if it needs a restart to "see" new maps. Anyway, anything that can be done in a script can be automated and used in TFS as a task during a deployment process.
The CI part is in part managed by how you organize the code repository. I like having separate branches for DEV / QA / PROD - each with it's own set of deployment rules. DEV can be configured as a manual push to the target server by a developer for instance. QA triggered by check-in, upwards migration of DEV tested/approved code/maps. PROD (especially for those systems that are governed by SOX) would be surrounded with a robust change management system procedure to ensure code was signed off on in QA and triggered by a non-developer deployment person as a scheduled maintenance or emergency patch depending on purpose of change.
Please let me know what kind of details you might want or need that I probably didn't cover.
Happy integrating!
------------------------------
Lisa Edwards
Software Engineer / Subject Matter Expert
Rainbow Data Systems, Inc
Original Message:
Sent: Wed November 13, 2024 06:03 PM
From: Rex Chan
Subject: Using CI/CD
Does anybody have experience using CI/CD for ITX map development and deployment? If you do, please share your experience and the product you use.
------------------------------
Rex Chan
------------------------------