Difference between revisions of "GCcode/ConceptCase"
| (8 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| + | == Context == | ||
| + | * Proposed initiative: Integration of GCcode within the GCTools suite | ||
| + | * Department: Treasury Board Secretariat | ||
| + | * Assistant Deputy Minister: | ||
| + | * Business owner: Treasury Board Secretariat | ||
== Problem or opportunity statement == | == Problem or opportunity statement == | ||
| Line 4: | Line 9: | ||
<code>''Explain the business problem or opportunity that needs to be solved in one sentence.''</code> | <code>''Explain the business problem or opportunity that needs to be solved in one sentence.''</code> | ||
| − | Source code developed by GC | + | Current development of Government of Canada computer programs and solutions rely on mixed practices and version control systems specific to each department and agency. By providing a common place to develop and share development projects and solutions, there is an opportunity to reuse the same platform across departments in most cases. |
| + | |||
| + | Source code developed by GC employees (software engineering, scientists, researchers,...) to support key programs needs to be available for reuse across departments, and to be scanned for security vulnerabilities. | ||
== Current state or context == | == Current state or context == | ||
| − | <code>''Describe the current state in which the problem or opportunity exists. Provide evidence to support the business problem or opportunity. | + | <code>''Describe the current state in which the problem or opportunity exists. Provide evidence to support the business problem or opportunity.'' |
| − | Aspects to consider: stakeholders and users, business process, technology employed, information or data used, relevant legislation or policies, strategic alignment | + | Aspects to consider: stakeholders and users, business process, technology employed, information or data used, relevant legislation or policies, strategic alignment |
</code> | </code> | ||
| − | Each department has at least one source code repository to manage versioning, and | + | Each department has at least one source code repository to manage versioning, and the software development life cycle. Many departments have several source code repositories. About $1.5 million is spent annually by departments on maintenance of source code repositories, and their associated continuous integration tools. This is based on data from the Application Portfolio Management program's inventory of applications which covers mostly the large departments. Extrapolating to the whole of the GC, we estimate that at least $2 million is spent annually around the GC on source code repositories. |
== Root Cause == | == Root Cause == | ||
| − | Traditionally, software development | + | Traditionally, software development was done within departments without a view to reuse the code for other projects, or across departments. Massive online collaboration tools did not exist to easily share source code outside departments and the public. |
| + | |||
| + | The current instance of Gitlab, GCcode, has provided departments with a common place to share their custom code and to experiment quickly without the constraints of a department specific version control system. | ||
== Desired business outcome == | == Desired business outcome == | ||
| − | A common platform to develop and collaborate around source code will | + | Over the past few years, several public software development collaboration platforms have emerged and gained popularity. A few departments are already leveraging GitHub to co-develop source code with the public at large, using an open source license, and have also been using paid accounts to host non-public projects. |
| + | |||
| + | As such, we acknowledge that some of the software developed by departments is not for co-creation with the public or not yet ready for it. These projects may not be candidates for an open source licence immediately however this source code can and should be shared within the GC as a whole by default. Several departments are already using the GCcode platform (GitLab instance). To make this platform mainstream for all departments it requires continuous funding and support. | ||
| + | |||
| + | A common development platform to develop and collaborate around source code will | ||
| + | * help developers discover source code they can contribute to, or reuse across departments | ||
| + | * help developers share best coding practices | ||
* Decrease time and cost to build new solutions | * Decrease time and cost to build new solutions | ||
| − | * Reduce costs | + | * Reduce overall maintenance costs for source code repositories by eliminating duplication |
* Improve continuous integration (CI/CD) practices | * Improve continuous integration (CI/CD) practices | ||
| + | * Enable teams across the entire government to leverage best practices and tools for the development and reuse of source code in the GC. | ||
| + | ** Smaller departments may not have the financial resources to host and maintain such a development environment; by providing a common place for all to work together, we would be generating economies of scale beyond single departments. | ||
| + | * Automate and scale CI/CD with automation and leveraging corporate level tools like automated scanning of known security vulnerabilities and legal compliance. | ||
| + | * Enterprise standard use of open source components (inbound single version of package) | ||
| + | * Set enterprise wide policies as well as department specific policies (prohibit or authorize use of AGPL, MIT, exceptions, etc.) for software inbound. | ||
| + | * Identify duplicate custom code, reuse existing code and create communities around projects across departments. E.g.: meeting room reservation application from department A could be leveraged across the government and potentially even published as open source. | ||
| + | |||
| + | The use of GCcode is aligned with the GC Digital Standards "Work in the open by default" and "Collaborate widely". | ||
== Future state == | == Future state == | ||
| − | <code>''Describe the expected future state. | + | <code>''Describe the expected future state.'' |
| − | Aspects to consider: stakeholders and users, business process, technology employed, information or data used, relevant legislation or policies, strategic alignment | + | Aspects to consider: stakeholders and users, business process, technology employed, information or data used, relevant legislation or policies, strategic alignment |
</code> | </code> | ||
| + | |||
| + | GCcode has an established funding model with contributions from departments to cover the costs of maintenance, platform support and community engagement. The recurring yearly funding is estimated at $XX. The benefits of GCcode: | ||
Source code developers will be able to | Source code developers will be able to | ||
| Line 46: | Line 71: | ||
IT Security managers will be able to | IT Security managers will be able to | ||
* Quickly locate vulnerable software libraries at the departmental level or across departments | * Quickly locate vulnerable software libraries at the departmental level or across departments | ||
| − | * Automate application security scans to prevent | + | * Automate application security scans to alert departments and prevent costly emergency responses |
== Next Steps == | == Next Steps == | ||
| − | <code>''What are the planned next steps? | + | <code>''What are the planned next steps? '' |
| − | Are there any known time constraints moving forward? | + | Are there any known time constraints moving forward? |
</code> | </code> | ||
Latest revision as of 14:22, 6 December 2018
Context
- Proposed initiative: Integration of GCcode within the GCTools suite
- Department: Treasury Board Secretariat
- Assistant Deputy Minister:
- Business owner: Treasury Board Secretariat
Problem or opportunity statement
Explain the business problem or opportunity that needs to be solved in one sentence.
Current development of Government of Canada computer programs and solutions rely on mixed practices and version control systems specific to each department and agency. By providing a common place to develop and share development projects and solutions, there is an opportunity to reuse the same platform across departments in most cases.
Source code developed by GC employees (software engineering, scientists, researchers,...) to support key programs needs to be available for reuse across departments, and to be scanned for security vulnerabilities.
Current state or context
Describe the current state in which the problem or opportunity exists. Provide evidence to support the business problem or opportunity.
Aspects to consider: stakeholders and users, business process, technology employed, information or data used, relevant legislation or policies, strategic alignment
Each department has at least one source code repository to manage versioning, and the software development life cycle. Many departments have several source code repositories. About $1.5 million is spent annually by departments on maintenance of source code repositories, and their associated continuous integration tools. This is based on data from the Application Portfolio Management program's inventory of applications which covers mostly the large departments. Extrapolating to the whole of the GC, we estimate that at least $2 million is spent annually around the GC on source code repositories.
Root Cause
Traditionally, software development was done within departments without a view to reuse the code for other projects, or across departments. Massive online collaboration tools did not exist to easily share source code outside departments and the public.
The current instance of Gitlab, GCcode, has provided departments with a common place to share their custom code and to experiment quickly without the constraints of a department specific version control system.
Desired business outcome
Over the past few years, several public software development collaboration platforms have emerged and gained popularity. A few departments are already leveraging GitHub to co-develop source code with the public at large, using an open source license, and have also been using paid accounts to host non-public projects.
As such, we acknowledge that some of the software developed by departments is not for co-creation with the public or not yet ready for it. These projects may not be candidates for an open source licence immediately however this source code can and should be shared within the GC as a whole by default. Several departments are already using the GCcode platform (GitLab instance). To make this platform mainstream for all departments it requires continuous funding and support.
A common development platform to develop and collaborate around source code will
- help developers discover source code they can contribute to, or reuse across departments
- help developers share best coding practices
- Decrease time and cost to build new solutions
- Reduce overall maintenance costs for source code repositories by eliminating duplication
- Improve continuous integration (CI/CD) practices
- Enable teams across the entire government to leverage best practices and tools for the development and reuse of source code in the GC.
- Smaller departments may not have the financial resources to host and maintain such a development environment; by providing a common place for all to work together, we would be generating economies of scale beyond single departments.
- Automate and scale CI/CD with automation and leveraging corporate level tools like automated scanning of known security vulnerabilities and legal compliance.
- Enterprise standard use of open source components (inbound single version of package)
- Set enterprise wide policies as well as department specific policies (prohibit or authorize use of AGPL, MIT, exceptions, etc.) for software inbound.
- Identify duplicate custom code, reuse existing code and create communities around projects across departments. E.g.: meeting room reservation application from department A could be leveraged across the government and potentially even published as open source.
The use of GCcode is aligned with the GC Digital Standards "Work in the open by default" and "Collaborate widely".
Future state
Describe the expected future state.
Aspects to consider: stakeholders and users, business process, technology employed, information or data used, relevant legislation or policies, strategic alignment
GCcode has an established funding model with contributions from departments to cover the costs of maintenance, platform support and community engagement. The recurring yearly funding is estimated at $XX. The benefits of GCcode:
Source code developers will be able to
- discover tools to help them be more efficient, such as configuration scripts, user interface customizations.
- collaborate on common solutions
- decrease their learning curve for new technologies
- discover solutions which they can reuse to address their clients needs
- network and learn from their peers
Departments will be able to
- Reduce their IT costs by using common version control and CI/CD tools
- Reduce software development costs by reusing solutions for the same business need.
- Discover and retain talent
IT Security managers will be able to
- Quickly locate vulnerable software libraries at the departmental level or across departments
- Automate application security scans to alert departments and prevent costly emergency responses
Next Steps
What are the planned next steps?
Are there any known time constraints moving forward?
