Question
Cognizant Technology Solutions
US
Last activity: 31 Aug 2017 10:14 EDT
Version management in Openspan
1) How can we do version control & management in openspan while doing development ? Is there any option available in openspan training version which available in PDN ?
Accepted Solution
Pegasystems Inc.
US
Since they are on separate machines, they wouldn't be using the same exact interaction.xml file, however it would be identical internally. You should agree on a folder structure for each machine where you store each project/solution so that paths to things are identical across machines. I would suggest something like creating a PegaRobotics Folder in the Root of drive C (C:\PegaRobotics). Inside, create a folder for your specific named solution (i.e. CustomerServiceDashboard). Inside of here is where you'd place the Interaction.xml and create all of your adapter solutions and controller solutions.
For source control, you can use any kind that you like. None are specifically incompatible with OpenSpan that I am aware, however you will not be able to merge any of the files using the source control system. If you are looking for recommendations, I would suggest SVN.
Pegasystems Inc.
US
In Studio you can use the deployment version value to control versioning.
These version numbers are honored in management console.
Cognizant Technology Solutions
US
Thanks Grona. Few queries :
Basically our intention is how do we configure when we need to have multiple team members work in a project where we need to do proper version management ? Can the developers do check out/check in while working on the same file ?
Also what do you mean by "Management Console" ?
Pegasystems Inc.
US
If you are using version control software with Pega Robotics, you must exclusively check out items. The software you use cannot simply merge changes from multiple developers. Multiple developers cannot work on the same files at the same time. We've found it better to assign each developer to their own project and separate projects by adapter. One developer can perform the interrogation and automation of one application (adapter) and provide that project to the other developer(s).
He is referring to what was formerly called OpenSpan Management Console. It is not used for code version control as no code is stored in the console.
Cognizant Technology Solutions
US
Thanks Sasnt for your response . Few follow up queries :
You said : "If you are using version control software with Pega Robotics, you must exclusively check out items" .
1) Does Openspan has any OOTB capability to do the version control like PEGA or we need to use any other external tool to do version control in OpenSpan ?
2) Let's say we have a customer deliverable project for which we have 5 team members. Now to work in the project , do we need to install PEGA Robotics Studio in each of the 5 developer's desktop or we can have PEGA robotics studio installed as a central server and everybody in the team will access to server and work ?
Based on your response to question#2 , please advise us how we can divide the work within team and finally merge the code considering version control (if needed any) ?
Thanks a lot in advance for your time ..
Pegasystems Inc.
US
- Pega Robotics (formerly OpenSpan) Studio does not come with any source control built-in. You can pretty much use whatever software you like, however each file must be locked exclusively (i.e. no merging changes).
- Pega Robotics Studio is a desktop application, and thus requires installation on each user's machine. In addition, you must make sure that the application(s) you are integrating with are also installed on that machine.
When multiple team members are involved, we would assign each one to work with a specific application (adapter). These would be created in separate projects so that no resources are really shared except for the Interaction.xml (is using the Interaction Framework...activities, interactions, etc...). One developer would be assigned to work on the controller project. This is essentially the project that orchestrates the other automations/activities and deals with providing them their input parameters and handling their output.
When each developer finishes the project they are working on, these projects can be added into the controller by simply adding a reference to them. By separating everything by project, you remove most potential conflicts between developers.
Cognizant Technology Solutions
US
Thanks Sasnt. This does clarify some of my doubts but still few left . Here are they :
As I understood , each of the developer will create separate project on their own robotics studio which is installed in their machine.
One developer (say Lead) will work on the controller project .
Initially everyone will have their Interaction.xml file . Once individual development is complete , each developer needs to send their interaction.xml file to the the Lead who will merge everyone's ineraction.xml change .
So when we start , let's we create a project (say MainProject) under solution (say MainSolution) . This is the main controller project .
Now when each developer starts working on their project , do they need to create a project (Say Project1) under creating a solution (say MainSolution) ?
Similarly for developer 2 , is it Project2 under MainSolution ? My question is is it that the Solution name for all the developer will be same as that of the Controller project solution or it can be different also ? The project names will be definitely different .
Also when we finally move all the individual projects to the Lead's machine for integrating everything , how does it happen ?
Thanks Sasnt. This does clarify some of my doubts but still few left . Here are they :
As I understood , each of the developer will create separate project on their own robotics studio which is installed in their machine.
One developer (say Lead) will work on the controller project .
Initially everyone will have their Interaction.xml file . Once individual development is complete , each developer needs to send their interaction.xml file to the the Lead who will merge everyone's ineraction.xml change .
So when we start , let's we create a project (say MainProject) under solution (say MainSolution) . This is the main controller project .
Now when each developer starts working on their project , do they need to create a project (Say Project1) under creating a solution (say MainSolution) ?
Similarly for developer 2 , is it Project2 under MainSolution ? My question is is it that the Solution name for all the developer will be same as that of the Controller project solution or it can be different also ? The project names will be definitely different .
Also when we finally move all the individual projects to the Lead's machine for integrating everything , how does it happen ?
Assuming that the solution name for all the project remains same , do we need to move all the projects under solution MainSolution or just adding a reference is sufficient irrespective of the name of the solutions of the individual project whether they are same or different (from Mainsolution).?
Pegasystems Inc.
US
- Ideally you will agree on the Interaction.xml beforehand. You don't want to try to merge everyone's changes there since that is really the interface between projects, you want to ensure it is pretty well-defined.
- Each developer should create their own solution/project. The controller can then reference these projects, but they shouldn't create it under the existing solution.
- Each developer will create a completely separate project/solution. They would all be using the same Interaction.xml, but otherwise, they would be 100% independent of each other.
- To move them all into one solution, the lead developer (the one who built the controller), would copy the individual projects into their folder and add them into the existing solution (right-click in Solution Explorer and select Add Existing Project).
- The projects are simply copied over. Ideally, they are checked into and out of source control.
- The solutions that the developers create are immaterial. The only one that you care about is the controller solution. We name our solutions (assume we are creating an adapter project for the Notepad application) NotepadSln and the project would be NotepadPrj.
Cognizant Technology Solutions
US
Thanks Sasnt for the detailed response.
One query on point#3 : This is regarding Interaction.xml . As I understood in the main solution or in the controller solution we can have only one Interaction.xml file . But individual developer will have their own copy of Interaction.xml file . So lead must first bring all the separate copies of Interaction.xml into the system where main Interaction.xml is present and then merge (either manually or using some editor merging tool) to have the final consolidated Interaction.xml file .
But in #3 , you mentioned below :
"Each developer will create a completely separate project/solution. They would all be using the same Interaction.xml ."
My query is : How can all the developers use the same Interaction.xml in different machine ?
Also in #5 , you mentioned about check-in/check out option thru source control tool .
Can you please tell us which source control tools are compatible and can be used with Openspan ?
Cognizant Technology Solutions
US
Hi Sasnt,
One query on your response . What do you mean by below statement :
"In addition, you must make sure that the application(s) you are integrating with are also installed on that machine."
"On that machine means" which machine do you refer to ? Do you refer to the developer's machine where openspan is installed ?
Pegasystems Inc.
US
Any applications you are integrating with must reside on the same physical hardware and running under the same user account and operating system as both Runtime and Studio (or the Studio Plugin). That means you cannot integrate with an application running under another user account, or with an application running on a remote computer that you access via RDP. Essentially, the exe you wish to integrate with must appear within your Task Manager when you are viewing the running processes.
Accepted Solution
Pegasystems Inc.
US
Since they are on separate machines, they wouldn't be using the same exact interaction.xml file, however it would be identical internally. You should agree on a folder structure for each machine where you store each project/solution so that paths to things are identical across machines. I would suggest something like creating a PegaRobotics Folder in the Root of drive C (C:\PegaRobotics). Inside, create a folder for your specific named solution (i.e. CustomerServiceDashboard). Inside of here is where you'd place the Interaction.xml and create all of your adapter solutions and controller solutions.
For source control, you can use any kind that you like. None are specifically incompatible with OpenSpan that I am aware, however you will not be able to merge any of the files using the source control system. If you are looking for recommendations, I would suggest SVN.