How to Clone from Test Org to Production When a Description Changes
In a previous article Paul Varley showed how you can implement a Version Control System for maps. Today we will talk about deployment pipelines and Continuous Delivery for TIBCO Cloud Integration solutions.
Having separate environments for testing and production is a useful development and release management best practice that can prevent bugs in production. At the same time, this practice creates another problem – moving changes between testing and production and ensuring they stay in sync over time. Of course, it can be done manually, but this is error prone and inefficient. Here’s where Continuous Delivery (CD) arises. In this article we will explore one of the ways we can apply CD to TIBCO Cloud Integration solutions with help of the API Connector.
We have two TIBCO Cloud Integration organizations: Testing and Production. We want to automatically clone solutions from Testing to Production when they’re ready for production.
First, we should install the Scribe Platform API connector from the Marketplace and establish the connection to Scribe Platform API.
Next, let’s create integration solution with name “Continuous Delivery” in the Testing organization. This solution will clone other solutions to the Production organization when they are ready. The Testing organization has solutions that we want to clone to the Production organization when they’re ready. “Integration Solution” is one of them.
The following diagram illustrates the initial state :
Iteration #1: The basis
How will we determine that a solution is ready to deploy into Production? We can use several conventions: for example, we putting “Production Ready” in the description of solutions ready to deploy into production. So, let’s create in “Continuous Delivery” solution a new map with the name “Clone Production Ready Maps to Production Org” which will:
- Query all solutions from the Testing organization
- Clone any solutions whose description equals “Production Ready” to Production
- •Note that this comparison is case-sensitive – so put exactly the same string as the solution’s description (without extra whitespace)
The CloneSolution command requires that you fill in the following fields:
- DestinationOrganizationId — ID of the target Organization where the Solution is being copied to.
- DestinationAgentId — ID of the Agent in the target Organization to associate with the copied Solution.
- OrganizationId – ID of the source Organization.
- SolutionId – ID of the source Solution.
In our example, we use hard-coded DestinationAgentId, but you could also use a Fetch or Lookup block with the Agent entity.
Iteration #2: Redefine the production readiness
Let’s run the map. Whoops, we got an error: “All maps must be valid to Clone a Solution”. According to API documentation “To successfully clone a Solution, all Maps in the source Solution must be valid, and the destination Organization must use the same Connection types and names. The cloned Solution is incomplete until a Solutions POST prepare command is issued against it”.
Based on this, it like we should filter out all incomplete solutions because we can’t clone them.
Let’s try to put “Production Ready” in the description of “Integration Solution”, run “Continuous Delivery” solution, and check the Production organization…
Whoo-hoo, we have the first solution successfully passed through our deployment pipeline!
Iteration #3: Preventing duplicate cloning
What if we run our “Continuous Delivery” multiple times? What will happen with already cloned solutions? It looks like our map clones all production-ready solutions on every run.
We implemented a basic scenario for cloning solutions from our Testing organization to Production. Here are some ideas for those of you who want to take this a step further. Consider implementing one or both of the following:
- Fetch the most suitable agent (for example, by name) instead of hardcode Agent IDs
- Use Lookup Tables instead of hardcoded “Production Ready” descriptions. Both of the options should work:
- good old formula editor
- or fetch block for Lookup Table Values of Scribe Platform API Connector
I hope that this article piqued your interest in exploring features of Platform API Connector and its possibilities. You’ve got this!
This blog post was created by Aquiva Labs. Learn more about their services here.
First Published March 12, 2018
About the Author
Vladimir Almaev is a software architect, polyglot developer and team lead at Aquiva Labs. His professional interests include programming languages and paradigms, software design and architecture, continuous integration, and hacks for personal productivity. He was lead developer on the Aquiva Labs team that partnered with Scribe on the Scribe Platform API Connector. While not working with software, Vladimir enjoys reading, drawing, listening to music, running, and practicing martial arts.