Branching Strategy

Release Mgt: Branching Strategy Michael Egan Nov 19, 2003

Terms of Reference ♦ Deployable – a Clearcase element (source, library, executable, configuration file, ddl, etc.) associated with an application.

♦ Site – physical or logical locus of deployables acting as an instantiation of an application or a set of applications (I.e., Lego Production, Tetris QA, PT Production, Facilitation Development).

♦ Site View – A Clearcase view whose config spec specifies deployables

appropriate for the site in question and action in question. For example, sites may have views for integrations, migrations, builds, and deployments.

♦ Environment – A site where the ability to change deployables is restricted to a select set of individuals (I.e., Production by GSD, QA-FTB by QA).

♦ Project – A site where deployables are created or modified to complete a SpeeDEV release.

♦ Migrate – The process of commingling deployable versions between an environment and a project.

♦ Build – The process of building binaries and configuration files based on deployables created or modified through a migration.

♦ Deploy – The process copying deployables from a site view to a site’s filesystem.

♦ Promotable – A version of a deployable considered able to be elevated to the next step in the development process. Criteria includes stability and functional completeness.

2

Scope ♦ Applications — —

Web Framework first. All remaining Program Trading applications by year end.

♦ Functionality — — — — —

Manage source/config at the project and sub-project (team) levels. Promote deployables from a project to an environment. Execute builds. Deploy deployables from environment view to environment filesystem. Scripts currently do not support members of the same project modifying same deployable at same time. May be supported if necessary.

♦ Deployables to be managed in Clearcase —

code + everything which influences runtime environment (config, DDL, etc.)

3

Roles and Responsibilities ♦ All —

Do not manually update config specs – only setcs via setcs.pl

♦ Developers — —

—

Reference SpeeDEV issue Ids when checking in/out code. Apply project team label to promotable versions. Criteria may be less restrictive to allow for more opportunities for development integration. If necessary, assist Dev Manager in resolving non-trivial merges during migration.

♦ Development Manager — — — —

Oversee unit testing of builds created for the project. Apply project acceptance label to promotable versions. Criteria must satisfy functional completeness and stability. Request migrations from project to environment. Resolve any non-trivial merges encountered during migrations.

4

Roles and Responsibilities (continued) ♦ Release Manager (using CC scripts) — — — — —

Setup project in Clearcase (once release approved in SpeeDEV). Initiate migrations from project to environment. Initiate builds for environments. Deploy deployables to environment filesystem. Apply REL labels prior to production deployment.

♦ QA —

Approve migrations to environments based on QA resource availability and quality of code.

♦ Program Office —

Ensure SpeeDEV status properly cues migrations, builds and deployments.

♦ GSD —

Execute & verify deployments from Production to PROD HUFS to Production filesystem.

5

Clearcase Objects, Infrastructure and Significance Branches

♦ Project branch – contains new versions associated with a project. — —

Naming pattern = /main/gbl_pr_<SD_Rls_id> setcs.pl sets cspec to handle branching, when necessary – For deployables which already exist in the production environment, modifications are placed upon the project branch. – For deployables which do not exist in the production environment, new deployables are left on the /main branch. – Branching facilitates multiple projects modifying the same deployable in parallel. For new deployables, only one project can modify the deployable since it is not visible to any other project.

♦ Environment branch - isolates versions specific to an environment. — — —

Naming pattern = /main/gbl_<env abbreviation>. Ex., qa, stage. PROD environment branch = /main Contains the cumulative changes from all projects which have successfully migrated to that environment.

6

Clearcase Objects, Infrastructure and Significance Labels

♦ Project team label – used by developer to identify versions he/she affirms as promotable. — —

Naming Pattern = GBL_PR_<SD_Rls_Id>-. e.g., GBL_PR_26-TEAM1.

♦ Project acceptance label – used by Dev Manager to identify versions he/she affirms as promotable. — — —

Naming pattern = GBL_PR_<SD_Rls_Id>-MIG e.g.,GBL_PR_26-MIG During a migration, this label is used to identify project versions to be migrated to the target environment.

♦ Aggregate Environment Label – applied by migration process

to identify versions which should appear in the environment’s release view. — —

Naming pattern = GBL_<env abbreviation> e.g., GBL_QA, GBL_STAGE, GBL_PROD.

7

Clearcase Objects, Infrastructure and Significance Labels (continued)

♦ Project-Environment Label – applied by the migration process to versions introduced to the target environment from a particular project’s migration. — — —

Identifies which project introduced this version of the deployable Naming pattern = GBL_PR_<SD_Rls_Id>-<env abbreviation> e.g., GBL_PR_26-PROD.

♦ REL label —

Bank standard label applied to versions ready to be or deployed to PROD HUFS filesystem.

♦ SCM Base Label —

e.g.,GBL_CM - applied to the version of a Clearcase management script or associated meta-data which has been approved by the Change Management Team.

8

Clearcase Objects, Infrastructure and Significance Attributes

♦ Migration/Rollback Attribute — —

— —

Attribute: GBL_MIGRATION Naming pattern = <M|R>-GBL_PR_<SD_Rls_Id>_<migration counter> – <M|R> = migration or rollback – Migration counter – gets incremented each time a migration is performed from a particular project to a particular environment. Migration counter starts at 0. e.g., M-GBL_PR_26_0. Attributes are used in favor of labels to capture migration actions. – We generally don’t care how many migrations have been performed between a project and an environment (rollback is exception to this rule). – To reduce clutter in graphical vtree diagrams.

9

Clearcase Objects, Infrastructure and Significance Views and Config Specs

♦ Far fewer views than current CC environment to reduce view server load. — — —

1 view per project/team – for dev build – will be removed upon completion of project. 1 view per person (for development and unit testing). Exceptions may be obtained with approval.

♦ Config Specs will only be set via setcs.pl script. — —

Manually editing config specs will be strictly prohibited. setcs.pl facilitates Clearcase workflow in a consistent manner whereas manually setting config specs to facilitate the workflow is unreliable.

♦ Project Team cspec - will first look for the team label then the latest on the project branch, then at the main branch

♦ Migration/Merge cspec —

One per target environment (QA/prod)

10

Change lifecycle for a prod deployable*: Setup foo.c

foo.c

/main

/main/gbl_qa

Release ID 26 is established in SpeeDev A team of Developers, “TEAM1” is

0 GBL_PROD

1

assigned to the project.

0 1

GBL_QA

* “prod deployable” indicates that the deployable had previously been released to the PROD environment

Rel Mgr runs projectMaker.pl -creates branch: gbl_pr_26 -creates label: GBL_PR_26-TEAM1 -creates label: GBL_PR_26-MIG -creates label: GBL_PR_26-QA -creates label: GBL_PR_26-STAGE -creates label: GBL_PR_26-PROD -locks labels -rel management team retains ability to move all labels -project team retains ability to move team label -creates cspecs for project team -creates project integration cspec if more than one team is specified

11

Change lifecycle for a prod deployable*: Modify

GBL_PROD

foo.c

foo.c

/main

/main/gbl_qa

0

0

1

1

Developer runs setcs.pl and chooses Release ID 26, TEAM1. Developer works with foo.c until satisfied that it is right, then applies team label to affirm that version is promotable.

GBL_QA

gbl_pr_26 0 GBL_PR_26-TEAM1

1

* “prod deployable” indicates that the deployable had previously been released to the PROD environment

12

Change lifecycle for a prod deployable*: Migrate

GBL_PROD

foo.c

foo.c

/main

/main/gbl_qa

0

0

1

1 gbl_pr_26

GBL_PR_26-TEAM1 GBL_PR_26-MIG

2

Dev Manager applies proj acceptance label to affirm that these versions are promotable. Dev Manager verifies MIG label with labelManager.pl then requests migration from Release Manager.

GBL_QA

Rls Manager confirms QA is ready to accept a migration to QA env.

GBL_QA GBL_PR_26-QA Rls Manager performs QA Migration 0 for Release ID 26.

0

Dev Manager resolves any nontrivial merges during the migration.

1

Migration includes… - introducing foo.c@@/main/gbl_qa/2 -Applying environment-project label to foo.c@@/main/gbl_qa/2 -moving the environment label to foo.c@@/main/gbl_qa/2 -applies migration attribute MGBL_PR_26_0 Rel Mgr deploys object code/config from environment view to environment.

* “prod deployable” indicates that the deployable had previously been released to the PROD environment

13

Change lifecycle for a prod deployable*: Rollback

GBL_PROD

foo.c

foo.c

/main

/main/gbl_qa

0

0

1

1

QA discovers serious bug(s) with the code recently migrated from Release ID 26. foo.c is contributing to the bugs. QA (with advice from Dev Manager) decides the bugs warrant a rollback of the entire migration. Release manager executes rollback.

gbl_pr_26

2

GBL_QA

0

3

GBL_QA

GBL_PR_26-TEAM1 GBL_PR_26-MIG

1

* “prod deployable” indicates that the deployable had previously been released to the PROD environment

Currently, this involves -Reintroducing foo.c@@/main/gbl_qa/1 as foo.c@@/main/gbl_qa/3 -moving the environment label to foo.c@@/main/gbl_qa/3 -Remove proj-env label from foo.c@@/main/gbl_qa/2 -Since there was no prior version of foo.c which had the project-env label, do not reapply it. -applying the migration attribute R-GBL_PR_26-0 to foo.c@@/main/gbl_qa/3

14

Change lifecycle for a prod deployable*: ReMigrate

GBL_PROD

foo.c

foo.c

/main

/main/gbl_qa

0

0

1

1 gbl_pr_26

GBL_PR_26-TEAM1 GBL_PR_26-MIG

GBL_PR_26-TEAM1 GBL_PR_26-MIG

Dev resumes work on foo.c on the gbl_pr_26 branch. Developer works with foo.c until satisfied that it is right, then applies team label to affirm that version is promotable. Dev Manager applies proj acceptance label to affirm that these versions are promotable.

2

Dev Manager verifies MIG label with labelManager.pl then requests migration from Release Manager.

0

3

GBL_QA

1

4

Rls Manager confirms QA is ready GBL_QA GBL_PR_26-QA to accept a migration to QA env.

2

Release Manager performs QA Migration 0 for Release ID 26.

3

Dev Manager resolves any nontrivial merges during the migration.

* “prod deployable” indicates that the deployable had previously been released to the PROD environment

15

Change lifecycle for a prod deployable*: Prod Migrate

GBL_PROD GBL_PROD GBL_PR_26-PROD REL_PR_26

foo.c

foo.c

/main

/main/gbl_qa

QA approves build in qa environment for promotion to PROD environment.

0

0

Release Manager runs PROD migration 0 for Release ID 26.

1

1

QA tests in STAGE environment and signs off.

2

gbl_pr_26

2

0

3

1

4

Release Manager runs script to deploy Object code and configurations from PROD environment view to PROD environment filesystem. Release Manager applies REL label GBL_QA GBL_PR_26-QA to indicate code is ready to be deployed on PROD HUFS.

2 GBL_PR_26-TEAM1 GBL_PR_26-MIG

3

* “prod deployable” indicates that the deployable had previously been released to the PROD environment

GSD deploys contents of PROD environment filesystem to PROD HUFS.

16

Recap: Change lifecycle for a prod deployable*

Prod Migration 0

GBL_PROD

GBL_PROD GBL_PR_26-PROD REL_PR_26

foo.c

foo.c

/main

/main/gbl_qa

0

0

1

1

2

gbl_pr_26 0

QA Migration 0

Prod Migration 0

2

GBL_PR_26-TEAM1 GBL_PR_26-MIG

3

QA Migration 0 M-GBL_PR_26_0 applied to foo.c@@/main/gbl_qa/2 GBL_QA QA Migration 0

2

QA 3 Rollback 0

4

1

GBL_MIGRATION Attribute ------------------------------------

GBL_QA GBL_PR_26-QA QA Rollback 0 GBL_QA QA Migration 1 GBL_QA GBL_PR_26-QA

QA Rollback 0 R-GBL_PR_26_0 applied to foo.c@@/main/gbl_qa/3 QA Migration 1 M-GBL_PR_26_1 applied to foo.c@@/main/gbl_qa/4 Prod Migration 0 M-GBL_PR_26_0 applied to foo.c@@/main/2

QA Migration 1

* “prod deployable” indicates that the deployable had previously been released to the PROD environment

17

Change lifecycle for a new deployable: Setup & Modify new.c /main

Release ID 27 is established in SpeeDev A Team of Developers, “TEAM2” is

0 GBL_PR_27-TEAM2

1

assigned to the project. Rel Mgr run projectMaker.pl -creates branch: gbl_pr_27 -creates label: GBL_PR_27-TEAM2 -creates label: GBL_PR_27-MIG -creates label: GBL_PR_27-QA -creates label: GBL_PR_27-PROD -creates branch: gbl_pr_27 -creates cspecs for project team -creates project integration cspec if there is more than one team -locks labels -rel management team retains ability to move all labels -project team retains ability to move team label Developer runs setcs.pl and chooses Release ID 27, TEAM2 Developer performs mkelem to create, then enhances new.c until satisfied that it is right, then applies team label to affirm that version is promotable 18

Change lifecycle for a new deployable: Migrate new.c /main 0 GBL_PR_27-MIG GBL_PR_27-TEAM2 GBL_QA

1

Dev Manager applies proj acceptance label to affirm that versions are promotable Dev Manager verifies MIG label with labelManager.pl then requests migration from Release Manager. Rls Manager confirms QA is ready to accept a migration to qa env. Rls Manager performs QA Migration 0 for Release ID 27 Dev Manager resolves any nontrivial merges during the migration Migration includes… -Applies environment aggregate label -applies migration attribute MGBL_PR_27_0 Rel Mgr deploys object code/config from environment view to environment

19

Change lifecycle for a new deployable: Prod Migrate new.c

GBL_PR_27-MIG GBL_PR_27-TEAM2 GBL_QA GBL_PROD REL_PR_27

/main

QA approves build in qa environment for promotion to PROD environment

0

Release Manager runs PROD migration 0 for Release ID 27

1

Release Manager runs script to deploy Object code and configurations from PROD environment view to PROD environment filesystem QA tests in PROD environment and signs off. Release Manager applies REL label to indicate code is ready to be deployed on PROD HUFS GSD deploys contents of PROD environment’s filesystem to PROD HUFS.

20