20.6 Version Control Best Practices

Managing a team environment with version control can be a challenging task. Combining version control with Identity Manager Designer has its own set of issues. This section includes some tips and best practices for using version control with Designer.

20.6.1 Best Practices

  • Coordinate all Designer upgrades with your entire team. When you upgrade to a new version of Designer, many of the files in your project are changed by the project converter, so you need to coordinate with the rest of your team. In the ideal upgrade process, everyone checks in all of their changes, one team member runs the project converter and checks in the converted project, then everyone installs the new version of Designer and re-imports the project.

  • Coordinate deployment. When you are using version control and the same eDirectory server with multiple people, it is possible to overwrite changes. You should coordinate deployment with your team members to make sure that you do not overwrite other team members’ changes. Best practice is to assign one person to deploy a project to a production environment.

  • Assign policies. Assign one team member to a policy rather than having multiple team members work on one policy. Multiple team members writing and modifying shared policies in a driver is a recipe for disaster.

  • Define an acceptable Modeler layout for the team. Personal Modeler layouts in a team environment are only maintained if there is a version control conflict on the Modeler layout between your Modeler view layout and another’s Modeler view layout. If there is no conflict and you perform an update from the version control server, you get the last Modeler layout that was checked into version control.

  • Compare, Check in, and Check out the objects at the root level . This helps to ensure that all objects are stored in the version control repository.

  • Check in the project from the version control view for existing projects . You can check in from the outline view or project view as well, but it may cause performance issues.

  • Use the same version of Designer within the team when working with version control . This is because the newer version of Designer may create objects that the older version of Designer may not be able to process.

  • Update your Identity Vault before migrating from a test environment to a production environment . Change the IP address and the credentials of the Identity Vault to point to the production eDirectory server before you migrate the test eDirectory shared servers to the production environment.

  • Use a production environment administrator account that is located in the production server network . It is recommended to have the production environment administrator on the same network as the production server to avoid network or VPN issues. This is because, importing or deploying of designer projects to Identity Manager can be slow over VPN.

20.6.2 Managing Packages Best Practices

This section includes some best practices for managing packages in version control.

Creating Packages

  • A single user should be assigned to create a package and its newer versions, and then check in the packages to enable the other team members to add or modify the content of the packages.

  • A single user should be assigned to create a driver and check in the corresponding packages of the driver.

  • A Designer project cannot contain multiple instances of the same package. When you import or create packages in a version control environment, ensure that you do not import and then check in the same package and version already checked in by another user. Multiple instances of the same package, especially a common package used by more than one parent package or driver, can cause conflicts in Subversion.

Checking In and Updating Packages

  1. Check in the entire catalog, and check in the driver and the parent objects of the driver (if available).

  2. Update the entire catalog.

    This ensures that all the objects are imported into the designer workspace.

Upgrading and Downgrading Packages

A single user must be responsible to upgrade and downgrade the packages and check in.

20.6.3 Best Practice Scenarios

There is no one-size-fits-all scenarios for using version control with Designer. This section identifies some user situations that we used for best practice scenarios. These scenarios are specific step-by-step guides to be used in addition to those outlined in the Best Practices section.

One-Person Project

Figure 20-26 One-Person Project

Version control is very useful in a team environment, but it is also very useful in an individual environment. Version control allows a single developer to make backups, restore older versions, and have the freedom to explore project changes without risking data.

Alice decides to work on a project alone. She creates a new project and checks that project in to the version control server. She makes changes to the project and deploys them to a development server for testing. She frequently checks her changes into the version control server so she can easily explore the history of her project later.

Alice can optionally use tagging to specify which project revisions are stable revisions. If she is unsatisfied with any project changes, she can revert those changes or get an older copy of her project from history. When she is happy with her changes, she deploys the project to an eDirectory server in the production environment.

Small Team with One Shared eDirectory Server

Figure 20-27 Small Team Scenario #1

Alice, Bob, and Carol are working together on a project. They are assigned the following roles:

  • Alice - Administrator

  • Bob and Carol - Engineers

Alice creates the new project and checks it into the version control server. Bob and Carol import that project and they all work on the project together. Alice, Bob, and Carol agree on ownership of Identity Manager objects and do not often edit each other’s objects. When Alice, Bob, or Carol want to deploy their changes to the shared development environment, they are careful to deploy just their own changes and not corrupt or overwrite the common objects that can overlapped during development. Everyone is diligent about updating frequently in order to avoid conflicts.

They all deploy to the same shared development server so they can test their changes in the same environment. When each team member is happy with the results, they check in their changes to the version control server.

When they are ready to deploy their project to an eDirectory server in the production environment, Alice performs an update to get the latest changes from the version control server and then deploys the project to the production server. Alice manages all deployment to the production server so the team maintains control over the changes in the production environment.

Small Team with Individual eDirectory Servers

Figure 20-28 Small Team Scenario #2

Alice, Bob, and Carol work together on a project. They are assigned the following roles:

  • Alice - Administrator

  • Bob and Carol - Engineers

Alice (the administrator) creates a new project and checks it into the version control server. Bob and Carol then import that project and they all work on the project together. Alice, Bob, and Carol don’t need any boundaries for object editing and they are all welcome to edit every object in the project. They update frequently and resolve conflicts when they occur.

Alice, Bob, and Carol each have their own eDirectory development server to deploy to and can deploy changes without the need to consult each other. They change, deploy, and test their changes and then check them into the version control server.

When they are ready to deploy to the production server, Alice updates her project to get the latest changes from version control and then deploys them to her development server. After she has verified that everything works as expected, she deploys the changes to the eDirectory server in the production environment. Alice manages all of the deployment to the production server to make sure it is a controlled environment.

Medium-Sized Team with a Shared Test and Production Environment

Figure 20-29 Medium Team Scenario

Alice, Bob, Carol, Dave, and Edgar all work together on a project. The following roles are assigned to all team members working on this project:

  • Alice - Administrator

  • Frank, George, and Hector - Part time consultants

  • Bob, Carol, Dave, and Edgar - Engineers

  • Ingrid - Integration Test Engineer

  • Pat - Production Environment Administrator

Frank, George, and Hector work part-time on this project and consult for other projects. Alice (the administrator) creates the project and checks it into the version control server. Bob, Carol, Dave, and Edgar import the project from the version control server and they all begin working on the project and deploying to the same eDirectory development server.

Frank, George, and Hector work mostly in an advisory capacity and do not own any objects in the project. They consult with Alice before making changes. Frank, George, and Hector are careful when they deploy changes so that they don’t overwrite the changes of the object owners.

Alice, Bob, Carol, Dave, and Edgar mostly focus on changing their own objects, but Ingrid (the integration test engineer) focuses on testing the entire project on a separate development server. She imports the project from version control and updates frequently to get changes from the rest of the team. She deploys those changes in the controlled development environment and tests them there. Ingrid makes only the changes necessary to deploy to the test server and does not check any changes into the version control server.

When Ingrid is satisfied with a version of the project, she creates a project tag in version control and certifies that revision of the project as deployable to the production environment. She then asks Pat (the production environment administrator) to deploy the project to the production server and tells him which tag should be deployed.

Pat imports the project from the version control server. He then uses the Get from History function to get the specific revision that Ingrid has tagged. After he has that version, he makes only the changes necessary to deploy the project to the production server and deploys the project. The rest of the team can continue to work on the project during this time because Pat has locked his version of the project to the revision that Ingrid has certified as deployable to the production environment.

Single Consultant Working for Multiple Companies

Figure 20-30 Working for Multiple Companies

Constance (the consultant) works for multiple companies, helping them with their Identity Manager projects. On Monday, she works for Ancillary Incorporated. She imports the project from the version control server at Ancillary Inc. and deploys the project to the Ancillary development server. Constance communicates frequently with the Ancillary Inc. team members and makes sure to never overwrite the objects from the Ancillary Inc. team on the eDirectory production server.

On Tuesday, Constance works for Beyond Limited. She closes the Ancillary project and imports the project from the Beyond Limited version control server. She follows established procedures when working with the Beyond Limited team and carefully separates the changes for each company.

20.6.4 Subversion and Version Control Interaction Rules

  • Do not use the Subversion command line. People familiar with the Subversion command line might be tempted to use it with Designer to perform simple commits or updates. Designer has many tools to manage the merging and object dependencies within an Identity Manager project. Using the Subversion command line bypasses these tools and can easily lead to a corrupted project and data loss.

  • Do not use other Subversion clients. Tortoise, Subclipse, or any other Subversion client can cause the same problems as the Subversion command line. Do not use them on the same working copy you are using for Designer.