CIC Studio provides tools that encourage team development activities and enable object versioning features. These tools are delivered via a set of context menu options and perspectives for working with a version control system (VCS).
The use of a VCS is what enables you and your team members to work collaboratively on Projects, more easily figure out the differences between versions of Projects, merge versions of Projects, and see the pedigree of a Project. It provides the necessary checks to prevent newer versions from being overwritten, and tools for merging other team member's changes into your own working versions.
Cleo recommends that you place your Studio Projects under version control immediately after creating them. This allows other team members to gain access to your Projects, provides an audit trail, and encourages you to synchronize your work with your team more frequently and methodically.
Note: Although it is not required to use a VCS, Cleo advises it for several reasons:
- It encourages team development best practices that have been accepted and embraced by the technology industry as a whole.
- It creates a single point of backup for mission-critical project assets.
- It makes the job of building and maintaining integration projects much more methodical and therefore less prone to errors.
All of your work in the Studio starts in the local Workspace – a private location on your machine that only you have access to. Whether you create Projects from scratch or check them out from a shared VCS repository, your local Workspace is the place where you do your work. There are several advantages to this:
- You can do work while disconnected from the cloud server and the VCS repository.
- Until you commit your changes to the repository and deploy your Project to a server, only the changes you’ve made are in your local Workspace.
Using Apache Subversion (SVN)
Cleo recommends Apache Subversion as the preferred VCS for use with Studio, which contains a plugin for interacting with an SVN server. For more detail on Apache Subversion, see http://subversion.apache.org
There are two parts to using Subversion: the client and the server. CIC Studio has a SVN plugin (client) integrated into the design-time tooling set. The only thing for you to do is to learn how and when to use it. The SVN server, on the other hand, is something you must install and maintain, or purchase as a service. There are a number of good options for either on-premise distributions or off-premise services. The Studio works with either option (or both at the same time, if desired) equally well.
Your organization may already use Subversion either on- or off-premise. If this is the case, contact the person responsible for maintaining the service and request a new repository for your Projects. You are encouraged to organize your CIC Studio resources into smaller, cohesive Projects. Each Project should be added to the Subversion repository you’re using.
A Subversion repository, by default, has three main concepts implemented as folders: Trunk, Branch, and Tag. It’s important for you to understand what these mean and how they’re used in order to maximize the benefit from using SVN.
- Trunk: This area represents the development of ongoing work in a transformation.
- Branch: Typically created from the Trunk, this area represents the tested and approved versions of the objects post-development.
- Tag: This is a convenient way to declare a snapshot in time of a Project in either the Trunk or in a Branch. These are useful for milestones in your Project development, enabling you to have a record of the state of a Project at an important time. Tags are also useful in giving you a baseline from which to view the differences between the snapshot and Branches, or the Trunk.
The CIC Studio contains a SVN plugin integrated with other design-time tools. This is important because the plugin delivers client tools for interacting with SVN right where you need them. Working with the client is done via:
- The SVN Repository Exploring perspective, used to define SVN Repository locations you are interacting with. The locations correlate directly to a directory on a SVN server, and are typically communicated with via HTTP. Repository locations are treated the same whether they are on- or off-premise.
- The Team context menu for resources in the Workbench perspective (menus are made available by selecting resources and right-clicking).
- The Team Synchronizing perspective, which provides a consolidated view of Projects in your local Workspace and their versions in the SVN Repository. Evident are all of your local changes that haven’t been committed to the SVN Repository, as well as changes committed by other team members to the SVN Repository that have not been brought into your Workspace. Merging and diffing tools are available, and you are encouraged (by the tooling) to view local changes to your Projects as Changesets rather than as individual isolated changes.
- Share your Projects with your team by putting them in an SVN Repository.
- Synchronize your local Workspace with the SVN Repository regularly – this minimizes the amount of merging you need to do over time.
Note: SVN purposely excludes certain system-generated Java from version control.
- Commit Changesets (groups of changes that go together) to the SVN Repository as often as you can.
- Work in a Branch if Project modifications are going to take more than a day or two.
- Commit your Changesets to the Branch as often as possible (many times per day) and, when everything is working in the Branch, merge the entire change back into the Trunk.
- Minimize the number of non-committed local changes in your Workspace.
- Use the Team Synchronization perspective as the primary method of interacting with the SVN server. Do not use the Team context menu for interacting with the SVN Server, unless you require a function that is not available in the perspective.