18.6 Version Control Best Practices

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

We encourage you to send in your version control best practices so we can make the user experience better for our product. Send your version control best practices via email to dvandenbos@novell.com. Entitle the correspondences “Version Control Best Practices.”

18.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. Choose a Modeler layout that the team can live with and leave it alone.

18.6.2 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 18-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 into 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 18-27 Small Team Scenario #1

Alice, Bob, and Carol are working together on a project. Alice (the administrator) 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. Everyone is diligent about updating frequently in order to avoid conflicts.

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 overwrite each other’s changes. 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 18-28 Small Team Scenario #2

Alice, Bob, and Carol work together on a project. 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 18-29 Medium Team Scenario

Alice, Bob, Carol, Dave, and Edgar all work together on a project. 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 18-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.

18.6.3 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.

  • Disable Subclipse before using version control with Designer. Subclipse is a great tool, but it does not work well with the Subversion integration in Designer for Identity Manager. It is not enough to just not use Subclipse, you must make sure it is disabled if you have it installed.

    This only affects those who run Designer inside Eclipse instead of using the Designer install, so most users will not see this problem.