This chapter includes the following sections:
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. Also supports using an HTTP or HTTPS proxy server. Not secured.
Passwords are sent over the network in plain text. It should be avoided where security is a concern.
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/Git Basic Authentication:
Basic user name and password based authentication over custom SVN protocol supported by
Note:Git basic authentication happens only through the Git URL provided. There is no user name or password.
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.
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.
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.
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.
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.
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.
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.
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.
Create folder to have a snapshot of entire folder for:
Sync deleted, moved or renamed objects state with VCS
Restore folder with children later
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.
Create Tag when objects are ready for testing.
Create Deployment Archive (DA) from the Tag.
Apply DA in the Testing environment.
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.
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.