Branching and tagging in Talend - 6.3

Talend Software Development Life Cycle Best Practices Guide

EnrichVersion
6.3
EnrichProdName
Talend Big Data
Talend Big Data Platform
Talend Data Fabric
Talend Data Integration
Talend Data Management Platform
Talend Data Services Platform
Talend ESB
Talend MDM Platform
Talend Real-Time Big Data Platform
task
Administration and Monitoring
Deployment
Design and Development
EnrichPlatform
Talend Administration Center
Talend Artifact Repository
Talend CommandLine
Talend Repository Manager
Talend Studio

Best practices for Git:

  • All developers should work on Jobs in the 'master' of the Development environment.

  • For each development (bug, new features), a local feature branch can be created and then pushed to the remote repository when the developer wants his or her work to be reviewed.

    On a Git remote project, Branches are either remote (Remote Mode, default mode) or local (Local Mode) branches. When a developer works in local or offline mode on a Git project, he/she is working on the local branch associated with the branch he/she last worked on, and changes are automatically committed to the local Git repository. Once the feature is ready, the developer needs to push the commits to make it a remote development branch before merging this remote branch to the 'master' when the feature is tested.

    Unlike SVN, in Git a remote branch is created on the whole repository and thus is available in all projects of this repository.

    For more information on how to work on local and remote branches, see the Talend Studio User Guide.

  • Each time developers reach a Milestone (for releases, features, sprints, etc.), a Tag should be used. A new Tag should be created when the feature is ready for delivery (Production environment). If the tagged version needs bug fixing, a branch can be created from the Tag and the fix can then be included in the 'trunk'/'master'.

  • It is recommended to define patches as minor versions and full releases as major versions.

  • When working in a specific branch, it is recommended to filter the project on this branch using the Git Branches whitelist option in order to reduce the use of disk resources and improve performances. For more information on this option, see the Talend Administration Center User Guide.

Best practices for SVN:

  • All developers should work on Jobs in the 'trunk' of the Development environment.

  • When a new intermediate release is required, the 'trunk' needs to be copied in its entirety to the new Branch or Tag.

  • Each time developers reach a Milestone (for releases, features, sprints, etc.), a Tag should be used. A new Tag should be created when the feature is ready for delivery (Production environment). If the tagged version needs bug fixing, a branch can be created from the Tag and the fix can then be included in the 'trunk'.

  • It is recommended to define patches as minor versions and full releases as major versions.

  • When working in a specific branch, it is recommended to filter the project on this branch using the SVN Branches whitelist option in order to reduce the use of disk resources and improve performances. For more information on this option, see the Talend Administration Center User Guide.

Talend provides a number of tools for branches and tags management, which are covered below.

You can create and edit branches and tags:

  • on the Projects page of Talend Administration Center with the Branch Management option,

  • using the MetaServlet with the createBranch and createTag commands,

  • using the Repository Branch management menu in the Studio Repository.

Once the branch or tag has been created:

From Talend Administration Center, you can create an execution task on a Job located in this specific branch or tag via the Job Conductor page. For more information, see the Talend Administration Center User Guide.

From Talend Studio, you can also switch between branches and tags. For more information, see the Talend Studio User Guide.

From Talend Repository Manager, you can move your projects from one branch to another. For more information, see Continuous Integration: Deploying to QA and Production environments.

Tags also allow you to fix errors on the exact same version as the one used to deploy the Jobs during the previous development phases.