Skip to main content

Information Technology Strategy Team

Version Control Systems Strategy

Last modified: 2020-11-05 Document Version: 0.01
This is a DRAFT 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):

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:

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:
  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.

Outcome Action Description Lead Contributor(s)
Architecture Finalize endorsement of ESDC OSS Management Framework Endorse the implementation of the framework (already in progress) EA Senior Mgmt
?
Update ESDC OSS Management Framework Update ESDC OSS Management Framework with best practices on publishing open source code, and by describing the capabilities and expected usage of each approved VCS EA DevCoP
IT Strategy
?
Define best practices and standards Define best practices, standards and procedures for using Git-based version control systems DevCoP EA
Senior Advisors
Enterprise Ops
BIS
APM
ITSM
?
Operations GCcode:
Provide official support
Determine the most appropriate model for providing official support in GCcode with the current owner (SSC) Software Design Services (SDS) SSC
TBS
DevCoP
EA
IT Strategy
?
GCcode:
Organize projects and monitor
Organize ESDC projects in GCcode and monitor usage Software Design Services (SDS) ?
GCcode:
Enable connectivity to the Internet
Enable projects in GCcode to deploy to public cloud service providers DevOps CoE DevCoP
Cloud CoE
SSC
Senior Advisors
IT Security
?
Development GCcode:
Enable DevOps capabilities
Ensure DevOps capabilities are available in GCcode, such as:
  • Continuous Integration (CI)
  • Continuous Deployment (CD)
DevOps CoE SSC
DevCoE
?
Migrate projects to GCcode Migrate software-related projects, scripts and system/database configurations to the chosen VCS, and gradually sunset legacy version control systems Development teams DevCoP
Operations teams
?
Communications Train staff Offer training resources to IITB staff related to DevOps and VCS Learning Branch DevCoP
?

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)
Metric Collection Method
Target Model Conventional Model
Number of projects and users (compared to total) Automatic
Manual
Percentage of team's code, configuration or scripts stored Automatic
Manual
How easily and quickly can teams leverage VCS in their work (high, medium, low) Manual
(Survey)
Manual
(Survey)
Level of activity of projects (issues, commits, deployments, etc. - high, medium, low) Automatic
Manual
User Satisfaction (high, medium, low) Manual
(Survey)
Manual
(Survey)

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

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

Acronym Definition
ARC Architecture Review Committee
CCoE Cloud Centre of Expertise
DevCoP Development Community of Practice
EA Enterprise Architecture
IITB Innovation, Information and Technology Branch
SSC Shared Services Canada
View this page on GitHub