Skip to content

Commit

Permalink
Change Potential Scenarios in Recommendation + fixes
Browse files Browse the repository at this point in the history
  • Loading branch information
Gabriel Cossette committed Jul 17, 2019
1 parent 01511cb commit bfa798e
Showing 1 changed file with 26 additions and 47 deletions.
73 changes: 26 additions & 47 deletions Content/OfficalGCCodeSupport.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,9 +8,9 @@ To recommend the adoption of a decentralized version control system for all IT p

The latest updates to the [Directive on Management of IT](https://www.tbs-sct.gc.ca/pol/doc-eng.aspx?id=15249) have clearly identified 3 main requirements changes related to source code management in the GoC:

1. If a custom-built application is the appropriate option, **by default any source code written by the government must be released in an open format via Government of Canada websites and services designated by the Treasury Board of Canada Secretariat** [(C.2.3.8.3)](https://www.tbs-sct.gc.ca/pol/doc-eng.aspx?id=15249#claC.2.3.8.3);
2. **All source code must be released under an appropriate open source software license** [(C.2.3.8.4)](https://www.tbs-sct.gc.ca/pol/doc-eng.aspx?id=15249#claC.2.3.8.4);
3. Share code publicly when appropriate, and when not, **share within the Government of Canada** [(C.2.3.9.5)](https://www.tbs-sct.gc.ca/pol/doc-eng.aspx?id=15249#claC.2.3.9.5).
1. If a custom-built application is the appropriate option, **by default any source code written by the government must be released** in an open format via Government of Canada websites and services designated by the Treasury Board of Canada Secretariat [(C.2.3.8.3)](https://www.tbs-sct.gc.ca/pol/doc-eng.aspx?id=15249#claC.2.3.8.3);
2. All source code must be released under an appropriate **open source software license** [(C.2.3.8.4)](https://www.tbs-sct.gc.ca/pol/doc-eng.aspx?id=15249#claC.2.3.8.4);
3. Share code **publicly** when appropriate, and when not, share **within** the Government of Canada [(C.2.3.9.5)](https://www.tbs-sct.gc.ca/pol/doc-eng.aspx?id=15249#claC.2.3.9.5).

The use of source code version control is indeed a foundational tool for software development but each department currently manages its own source code independently. Moreso, there are even instances where multiple methods and solutions are in place to manage source code versioning within a single organisation.

Expand All @@ -20,23 +20,18 @@ In order to properly leverage this modern approach, a decentralized version cont
Many opportunities present themselves for individual departments (reference the [ESDC Development Community's GC Code Recommendation article](https://github.com/esdc-edsc/Welcome/blob/master/Recommendations/GCcode.md)), though for the Government of Canada as a whole as well.
With initiatives such as the OneGov movement and the GCTools from TBS, having a collaborative tool with powerful automation features available would deliver great benefits to our development communities, who are increasingly responsible for ensuring the delivery of modern services to Canadians.
By providing a common place to develop and share development projects and solutions, there is an exceptional opportunity to reuse the same platform across departments in most cases.
Presently many redundancies exist within departments as they each host and support local instances of varying source control solutions.
Presently, many redundancies exist within departments as they each host and support local instances of varying source control solutions.

## Existing literature

1. ESDC's Developer Community has written an [article](https://github.com/esdc-edsc/Welcome/blob/master/Recommendations/GCcode.md) promoting GC/Code as their preferred solution for a standardized source control.
The main set back of the tool is that it is unofficially supported, though given its benefits, ESDCs IT Strategy recommends that it should become the officially supported standard for all of the Government of Canada
2. A [wiki page](https://wiki.gccollab.ca/GCcode/ConceptCase) was written supporting the move towards a government wide standardized source control solution and makes a case for GC/Code.
The proposed initiative from the article is an integration of GC/Code within the GCTools suite
1. ESDC's Developer Community has written an [article](https://github.com/esdc-edsc/Welcome/blob/master/Recommendations/GCcode.md) providing guidelines on how to manage ESDC's projects in GC/Code.
2. A [wiki page](https://wiki.gccollab.ca/GCcode/ConceptCase) was written supporting the move towards a government wide standardized source control solution and makes a case for GC/Code. The proposed initiative from the article is an integration of GC/Code within the GCTools suite.
3. The Government of Canada Open Source Advisory Board started writing a [business case](https://github.com/canada-ca/OS-Advisory_Conseil-SO/blob/master/en/Working_Group_Tools/gc-source-code-repo.md) for a Source Code Platform to enable central hosting and sharing of source code.

## Situation

GC/Code is an instance of [GitLab Community Edition (CE)](https://gitlab.com/gitlab-org/gitlab-ce/), free open source software (FOSS) under the MIT license, hosted by Shared Services Canada (SSC).
GC/Code is currently unofficially supported by SSC with a "when time permits" policy.
It runs on production servers and has backups and receives semi-regular updates.
GC/Code is currently only available within the GoC Intranet, which does block the solution from access to 3rd party add-ons and some native features.
A number of departments are already storing a large amount of source code on GC/Code as their main source control solution.
GC/Code is currently unofficially supported by SSC with a "best effort" policy. It runs on production servers and has backups and receives semi-regular updates. GC/Code is currently only available within the GoC Intranet, which blocks the solution from access to 3rd party add-ons and some native features. A number of departments are already storing a large amount of source code on GC/Code.

### GC/Code Stats

Expand Down Expand Up @@ -66,11 +61,11 @@ To bring [GC/Code](https://gccode.ssc-spc.gc.ca) as an officially supported sour
With the current (as is) configuration of GC/Code, there are a few additional features that could be enabled to increase the viability of the tool:

* **[Pages](https://about.gitlab.com/product/pages/)** – To host documents and guides on the software in development, and even static websites including ones with GoC official theme.
* **[Shared Runners](https://docs.gitlab.com/runner/)** – For deployment directly to SSC infrastructure to manage production and development environments.
* **[Internal Runners](https://docs.gitlab.com/runner/)** – For deployment directly to SSC infrastructure to manage production and development environments.

With the tool exposed to the internet, there are a few other features that could be leveraged:

* **[Runners](https://docs.gitlab.com/runner/)** – For deployment to cloud infrastructure to manage production and development environments.
* **[Cloud Runners](https://docs.gitlab.com/runner/)** – For deployment to cloud infrastructure to manage production and development environments.
* **[3rd Party Integrations](https://docs.gitlab.com/ce/integration/)** – To add a variety of services to projects.
* **[Repository mirroring](https://docs.gitlab.com/ce/workflow/repository_mirroring.html)** – For multi-government and citizen collaboration.

Expand All @@ -80,51 +75,35 @@ With funding for the [GitLab Enterprise Edition (EE)](https://gitlab.com/gitlab-

There are arguments to support the adoption of GitHub over GC/Code. Mainly:

* **Leveraging the GitHub's infrastructure**<br>
* **Leveraging the GitHub's infrastructure**
The GC will not be able to compete with GitHub's resources and its ability to stay current, so it would be best to use GitHub from the get go and benefit from its sustainability capability.
* **Work in complete openness**<br>
* **Work in complete openness**
GitHub allows GC employees to work in complete openness with the rest of the world, turning repositories private only when needed.

However, this proposal counters these arguments to the favour of GC/Code for the following reasons:

* **Increase comfort level to openness**<br>
* **Increase comfort level to openness**
Some GC employees and IT Security personnel are reluctant to use GitHub due to security risks (e.g.: [accidently adding sensitive information like API keys in the repos](https://www.theregister.co.uk/2018/02/07/uber_quit_github_for_custom_code_after_2016_data_breach/)).
Using GC/Code is expected to augment the GC developer's community best practices around source control and, as such, increase assurance around management and IT Security personnel for open source project meant to be released to the public.
* **Vendor lock-in risk management**<br>
GitHub roadmap is determined based on industry funding, not by the GC's interests. Having our own internal instance reduces vendor lock-in by allowing GitHub repositories a second home.
* **Potential Cost Savings**<br>
* **Vendor lock-in risk management**
GitHub roadmap is determined based on industry funding, not by the GC's interests. Having our own internal instance running on open source software reduces vendor lock-in by allowing GitHub repositories a second home.
* **Potential Cost Savings**
Although a more fulsome cost evaluation should be performed when this proposal is adopted, it is believed that maintaining an internal instance would result in cost savings due to the requirement to host private repositories at the GC level.
* **Contribute to [GitLab Community Edition (CE)](https://gitlab.com/gitlab-org/gitlab-ce/)**<br>
* **Contribute to [GitLab Community Edition (CE)](https://gitlab.com/gitlab-org/gitlab-ce/)**
Having a hosted version of GitLab allows the GC to contribute more directly to the GitLab open source project.

## Potential Scenarios
## Recommendation

### Owner
We recommend that GC/Code becomes the official internal version control platform for the GC and that ESDC contributes toward this goal (e.g. funding through MOU) as it directly benefits from the platform.

In order to move forward with this recommendation, an owner interested in evolving the platform needs to be found. Potential candidates could be:
We anticipate that the following work will be needed:

1. **SSC CIO** – Application Development and Database Administration team (current owner);
2. **TBS GCTools** – Under the Open Accessible Digital Workspace project;
3. **PSPC Digital Services** – Due to mandate in providing these types of services; and
4. **ESDC IIT** – As ESDC's Development Community standardized on GC/Code.

### Business Model

A sustainable business model also needs to be determined, which would most likely involve user departments to contribute to the platform in some way, e.g.:

* **In-kind** – Each department provides 1 employee who is responsible 1 day/week to contribute toward the maintenance and constant improvement of the GitLab instance; and
* **Funding** – A flat fee per user per department is charged to those departments using the service.

### Costing

Finally, the cost required for the owner to host, support and evolve the platform will be dependent upon factors such as:

* **Support Level** – E.g. Period, Response time;
* **Hosting location** – SSC Data Centre or Public Cloud Provider;
* **Platform** – GitLab free or paid edition, or other options such as GitHub Enterprise; and
* **Maintenance** – E.g. Supported integrations, Frequency of updates, Monitoring.

All these potential scenarios will be further investigated once the proposal has been adopted.
1. Kick off discussions with SSC CIO ADDA (Application Development and Database Administration) team responsible for the current service;
2. Determine and plan evolution of the service (e.g. business model, service levels, hosting environment, additional features);
3. Present to relevant committees;
4. Set funding agreement(s) with ESDC and other departments as required;
5. Implement technical changes and formalize a support team within SSC; and
6. Rebrand the platform accordingly.

## Supporting members

Expand All @@ -144,8 +123,8 @@ All these potential scenarios will be further investigated once the proposal has
| PSPC | Steve Trotman | Programmer Analyst |
| TC | Stephen Bakalian | Programmer Analyst |
| PSC | Md Alam | Middleware Operations |
| DFO | Daniel Ricard | Senior Biologist |
| SSC | Jeff Barnes | Senior Advisor |
| DFO | Daniel Ricard | Senior Biologist |
| DFO | David Fishman | Data Manager |
| DFO | Pablo Vergara | Data Manager |
| CEDQ | Sebastien Metivier | Team Lead - Integration |
Expand Down

0 comments on commit bfa798e

Please sign in to comment.