22 Life Cycle Management Guidelines

This chapter provides the guidelines to be followed for using the Life Cycle Management features.

This chapter includes the following sections:

Guidelines for Choosing the Authentication Type

Please consider the following points before you choose the authentication type.

  • File Based Authentication:

    It provides direct access to repository through file system.

    It should be avoided as it removes any layer of protection between users and the repository. Users may accidently or intentionally corrupt the repository database.

  • HTTP Basic Authentication:

    Provides basic authentication through user name and password. Not secured.

    Passwords are sent over the network in plain text. It should be avoided where security is concern.

  • SSL Authentication:

    Same as HTTP Authentication while allowing to secure all network communication through secured socket layer (SSL).

    It should be used when VCS operations are performed over the Internet.

  • SVN Basic Authentication:

    Basic user name and password based authentication over custom SVN protocol supported by snvserve server.

    Not secured. Passwords are sent over network in plain text. It should be avoided where security is concern.

  • SSH Authentication:

    Same as SVN authentication while sending all network communication over SSH.

    Useful if you have an existing infrastructure that is heavily based on SSH accounts, and users already have system accounts on your server machine.

General Branching Guidelines

The following are the general branching guidelines that you must follow.

  • Use Trunk for the main code line where the future development takes place.

  • Use Branches for releasing code, for example, allowing stabilization, bug fixes, etc.

  • Use Branches for parallel development, for example, when you have geographically separated teams or functionally separated teams.

  • To minimize merges, keep branches to minimum and do not create personal branches.

  • Always merge between the Trunk and the development branches, or between the release main branch and the release development branches.

    Note:

    Never merge between development branches directly. This will create unmanageable code tracking.

  • Remember the VCS KEY configured for your repository with Trunk. The same VCS Key must be configured for all development branches so that encrypted content can be populated and merged effectively.

General Tagging Guidelines

The following are the general tagging guidelines that you must follow.

  • When development of a project feature is completed, create a partial tag with all relevant artifacts.

  • Create a tag for objects being released to QA or production through deployment archive. It will be useful for referring back to the released objects while bug fixing and debugging.

  • Create Full tags on your development trunk or branch periodically (weekly, fortnightly, or monthly). If something goes wrong with your current code you can revert back to the last available full tag.

  • If parallel development team is suppose to work on a subset of repository objects, then create a partial tag with only the relevant objects so that the development branch can be created only with the subset of objects.

  • Create a full tag on the Trunk or branch where changes are being merged so that pre-merge state can be restored if something goes wrong during merge.

  • Avoid merging branch artifacts directly. Rather perform branch merges through tags. Create a tag with the objects that are ready to be merged and then merge the changes to other branch or trunk using that tag.

  • Create a tag before detaching or erasing any existing work repository. The VCS copy of the work repository objects will be deleted as part of these operations. So creating the tag will allow you to resurrect the objects if needed.

Branching Guidelines for Single Development Team

Surrounding text describes branches_sd.png.

The following are the branching guidelines for single development teams.

  • Use Trunk for development until close to the release.

    Create Tags at various logical points.

  • Create dev branch for release when you are close to the release.

    • Use release branch for stabilizing code and bug fixing.

    • Use Trunk for developing next release items.

    • Merge changes from release branch to Trunk at various logical points.

  • At General Availability (GA).

    • Create Release Tag on the release branch.

    • Create Deployment Archives from the GA tag.

    • Merge changes from GA tag to the Trunk.

Branching Guidelines for Parallel Development Teams

Surrounding text describes branches_pd.png.

The following are the branching guidelines for parallel development teams.

  • Create separate development branch from Trunk for each parallel team.

  • At various logical points:

    • Create Tags on the team specific dev branch.

    • Merge code to Trunk.

    • Notify other team to merge the changes from Trunk.

Guidelines for Release Branches for Parallel Development Teams

Surrounding text describes releasebranches_pd.png.

The following are the guidelines for working with release branches for parallel development teams.

  • When close to the Release.

    • Create main development branch for the release from the Trunk.

    • Create a development branch for each team from the release's main branch.

  • At various logical points.

    • Create tags on the team specific release branch.

    • Merge code from teams release branch to release main.

    • Notify other team to merge changes from the Release main.

  • At General Availability (GA).

    • Create GA tag on Main Release branch.

    • Create Deployment Archive from GA tag.

    • Merge stabilized release code from GA tag into Trunk.

Guidelines for Versioning During Development

Surrounding text describes versioning_dev.png.
The following are the versioning guidelines that you must following during development.

  • Individual object version

    • Create version at stable check point. Discourage auto versioning since it gives you more control.

    • Periodically check stale versioned or non-versioned objects for the folder one is working on and create versions.

  • Folder Version

    • Create folder to have a snapshot of entire folder for:

      • Folder comparison

      • Sync deleted, moved or renamed objects state with VCS

      • Restore folder with children later

      Note:

      Individual object versioning is independent of folder versioning.

  • Create Versions of ODI objects at various logical points.

  • Ensure to create versions of all relevant objects to maintain consistency of ODI objects the VCS.

  • Have tags created at various logical points during development.

Guidelines for Deployment in Testing and Production Environments

Surrounding text describes deploy_testprod.png.
The following are the guidelines for deployment in testing and production environments.

  • Create Tag when objects are ready for testing.

  • Create Deployment Archive (DA) from the Tag.

  • Apply DA in the Testing environment.

    • File bugs.

    • Dev team to fix bugs and create new DA.

    • Continue testing with the new DA.

  • DA is ready for Production environment when all the bugs are resolved.

Guidelines for Initial Deployment and Patching

Surrounding text describes deploy_initpatch.png.
The following are the guidelines that you must follow for initial deployment and patching.

Initial Deployment Archive

  • Use for applying released artifacts.

  • Must contain all released objects.

  • Deploy initially on an empty repository.

Patch Deployment Archive

  • Use for deploying bug fixes and enhancements.

  • Must contain only the objects that are relevant to the fix or the enhancement.

  • Create a Rollback Deployment Archive while applying a Patch Deployment Archive, so that the patch can be rolled back if something goes wrong.