Version Control Systems Strategy

Table of Content

1. Introduction
   1. Purpose
   2. Target Audience
   3. Business Case
2. Guiding Policy
3. Coherent set of actions
4. Measuring the Strategy’s success
5. Appendix A - Traceability Matrix
6. Appendix B - Definitions
7. Appendix C - Acronym List Definition

Introduction

Purpose

To provide IITB with modern and supported Version Control Systems (VCS) for use in software projects, and a roadmap to get there.

This strategy is aimed at reducing the need to support various legacy version control systems, while increasing the collaboration and visibility between projects within ESDC, across the GC and publicly.

The strategy includes:

1. A Guiding Policy, which serves to set automatic decisions that defines the expected usage of the version control systems
2. A Coherent set of actions (an action plan), which serve to operationalize the version control systems

The intent behind this strategy is to communicate a decision by the CIO (not yet approved) on a path forward (the Guiding Policy), and what investments are needed to operationalize that decision (the coherent set of actions).

Target Audience

This strategy document is targeted to stakeholders involved in determining how IT Products are delivered. More specifically, stakeholders involved in defining the rules for building, delivering, operationalizing, and maintaining IT Products. The stakeholders are listed in section Coherent set of actions and are expected to participate in the execution stage of this strategy necessary to operationalize the Guiding Policy.

The Guiding Policy, once operationalized, will define the default systems where ESDC IITB will publish and maintain its source code, scripts, and system/database configurations. All ESDC personnel involved in the management of IT Products is expected to adhere to this policy, including but not limited to, development and operations staff.

Business Case

Moving to the digital age requires improving IT’s responsiveness.

To improve IT’s responsiveness, we must find ways to reduce risks associated with its use. This strategy proposes equipping ESDC with a set of modern and supported Version Control Systems, for use by all software-related projects, and in direct support with GC Digital Standards, ESDC Open Source Software (OSS) Management Framework (internal) and ESDC Target IT Solution Delivery Model strategy (in consultation). The benefits for the organization are numerous:

Benefits

• Reduce development costs through collaboration and platform consolidation;
• Strengthen relationships between IT and business through a common platform;
• Find, discover, reuse and share code quickly and efficiently across GC departments;
• Enhance planning and tracking of feature development through a single view;
• Accelerate development and deployment cycles;
• Increase software transparency;
• Improve the quality and security of code through continuous automated testing and external contributions (by working in the open);
• Ensure compliance with Information Management policies with lifecycle management;
• Attract IT talent;
• Reduce vendor lock-in by increasing capacity to support source code; and
• Obtain metrics/statistics for reporting and continuous improvement.

The Architecture Review Committee (ARC) already endorsed the usage of 3 version control systems in July 2019 (internal presentation):

• GitHub: Share with public (Unclassified);
• GCcode (internal): Share with GC (up to Protected A); and
• Azure DevOps: Share within ESDC (up to Protected B).

However, work remains in some areas to drive adoption. For instance, GCcode is not officially supported by SSC and lack some modern DevOps features (such as deployment to external cloud providers). This strategy’s goal is to define what the target state of the version control systems should be, and provide a roadmap in getting to this target state.

This strategy complements existing IT initiatives, such as ESDC IITB Way Forward, and supports them with new activities (see Coherent set of actions).

Guiding Policy

The following policy reflects the decision adopted by the CIO of ESDC (approval by CIO not yet obtained) regarding usage of the Version Control Systems. Each policy statement is a declaration of that decision and has received the endorsement of its associated area of governance body (endorsements not yet obtained, see Coherent set of actions).

This policy becomes active when IT Products are to be built. Once active, all teams involved in the project, and the IT products involved in the IT solution, must comply with this guiding policy.

This Guiding Policy has been prepared by taking into consideration alignment and compliance with existing policy instruments and does not replace them. Stakeholders are expected to still comply with existing policy instruments including, but not limited to:

• TBS Directive on Service and Digital
• TBS Directive on Security Management
• ESDC Information Management Policy (being drafted)
• ESDC Security Policy (being drafted)

Development and Operations Teams (incl. SSC)

1. Use a DevOps platform with a Git-based Version Control System (VCS) among the following options, in that order of preference:
   • Public (Unclassified): GitHub or another approved public platform (internal)
   • Interdepartmental (up to Protected A): GCcode (internal)
   • Internal (up to Protected B): Azure DevOps
2. Follow the guidance of ESDC Open Source Software (OSS) Management Framework (internal).
3. Leverage the functionalities provided by the selected VCS as much as possible, for instance:
   • File hosting (source code, scripts, system/database configurations…);
   • Issues (incl. milestones and Kanban);
   • Wiki (documentation);
   • Build and Test Automation (e.g., security-related); and
   • Deployment to internal or external platforms.
4. Make their projects in the VCS open by default, including for contributions.
5. Adhere to best practices defined in ESDC OSS Management Framework and GC Guide for Publishing Open Source Code, such as:
   • Project space is easily discoverable;
   • There’s a clear process to support and encourage external contributions (other employees, public);
   • Code of conduct is present;
   • Security disclosure process is in place for vulnerabilities;
   • Documentation (at least minimal) is published and maintained, and translated at each release (TBD);
   • Classified information and secrets are kept in proper tools and never hardcoded in the source code;
   • Source code security and compliance is automatically assessed on a continuous basis with tools and services; and
   • An up-to-date bill of materials is continuously generated and made available.

Coherent set of actions

The following are actions that need to be performed in order to make the Version Control Systems operational.

Measuring the Strategy’s success

This Strategy’s success will be measured by tracking the following metrics of VCS usage:

1. Number of projects and users (compared to total)
2. Percentage of team’s code, configuration or scripts stored
3. How easily and quickly can teams leverage VCS in their work (high, medium, low)
4. Level of activity of projects (issues, commits, deployments, etc. - high, medium, low)
5. User Satisfaction (high, medium, low)

Manual: the collection of data requires manual intervention (e.g., surveys, interviews, emails, spreadsheet updates).

Automatic: the collection of data is performed automatically, usually involving programmatic means (e.g., events triggered by a Git repository when a new commit is performed, which updates a master dashboard “view”).

Some of the metrics are based on DORA DevOps Research.

Appendix A - Traceability Matrix

The following traceability matrix is used to show alignment with various strategies, plans, and policy instruments already in progress.

Government of Canada Digital Standards / Work in the open by default

GC Architecture Standards / Application Architecture

Directive on Service and Digital - Appendix A: Mandatory Procedures for Enterprise Architecture Assessment

• A.2.3.8 Use Open Standards and Solutions by Default
• A.2.3.9 Maximize Reuse

IITB Way Forward / Strengthen IM/IT services and enhance the ESDC employee experience

Digital Operations Strategic Plan: 2018-2022

• Strategic Action #40 Section 4.4 / Introduce a strategy for use of open source software and open standards

Digital Nations Charter / 3.4. Open source

ESDC Information Strategy 2018-2023 / Principle 3. Information is Optimized for Use and Reuse

ESDC’s PwC Independent Study (upcoming) / Information Management

Appendix B - Definitions

Version Control System (VCS)
There are 2 types of VCS:

Centralized:
VCS are based on the idea that there is a single “central” copy of a software project somewhere (most likely on a server), and developers make code changes directly on this central copy.

Distributed:
VCS (DVCS) do not necessarily rely on a central server to store all the versions of a software project’s files. Instead, every developer “clones” a copy of a repository and has the full history of the project on its own hard drive. This copy (or “clone”) has all of the metadata of the original. In a DVCS, developers typically will make code changes on their local copy, test them on their local copy, and “push” them to a central server containing the “master” copy the software project is intended to use.

IT Solution
An IT Solution is the combination of 1 or many IT Products, which are in turn comprised of 1 or many Software and/or Hardware, obtained through many possible ways: built internally, obtained as open source, provided by a company as an executable application under a proprietary licence, as a standalone device, or used as a service through a subscription model.

IT Product
The combination of software, infrastructure, and their configuration. An IT Product is akin to an “application” as defined by the Application Portfolio Management (APM) program. An IT Product may have one or many software (e.g., COTS, open source libraries, open source software, custom-built software). Each of those software are deployed in one or many infrastructure (on premise, on the public cloud, or a combination of the two making it a hybrid deployment). For the scope of this Strategy, Operating Systems are NOT defined as IT products. Therefore should an IT Product depend on an Operating System to run in production, it is in compliance with this Guiding Policy.

Appendix C - Acronym List Definition