Permalink
Browse files

couple more text changes based on issue #105 and #101

  • Loading branch information...
jcastle committed May 26, 2017
1 parent 0ae9ac8 commit f33e8aa7804d0761ff2c294fafb977611bc14eee
Showing with 2 additions and 4 deletions.
  1. +2 −4 pages/oss-implementation.md
@@ -130,14 +130,12 @@ If your source code is in a version control system other than the GSA organizati
#### Modern code management practices
You should begin with reading [12Factor.net](https://12factor.net/) principles for code management, particularly [#1](https://12factor.net/codebase) and [#3](https://12factor.net/config) for proper modern code management practices. Questions around code base exposure commonly arise when we are out evangelizing OSS for the Agency. This suggests that we are not familiar with modern code management.
Furthermore, the twelve factors are for consideration with modern DevOps practices for custom SaaS. Each of our applications should be considered this way as we move away from large system type approaches, to scalable and manageable applications.
In particular, this approach supports one version of the *truth* in code and supports server/development environment management (in the cloud). Furthermore, it supports vendor turnover as the code is being managed publicly and processes supporting modern DevOps practices. This should allow a new vendor and GSA feds to smoothly transition new team members.
Having open source code creates one version of the *truth* in code and supports server/development environment management (in the cloud). Furthermore, it supports vendor turnover as the code is being managed publicly and processes supporting modern DevOps practices. This should allow a new vendor and GSA feds to smoothly transition new team members.
#### Scanning code for public release
As good IT project management and development practice, project teams should be conducting regular code reviews. This should be done in coordination with the contractor teams. One way to do this is for all project members to be included in the VCS (Version Control System) and to schedule regular code reviews. This should not be done at the end of a contract or end of a build cycle, rather should be done through the development/release cycle.
Furthermore, the project team should be working with the IT security office to conduct regular code scans. The CTO team works regularly with security and is creating two scripts ([#1](https://github.com/GSA/codeinventory-github) and [#2](https://github.com/GSA/codeinventory)) that project teams can use to scan their code. These scans are different than those done by security, as they are specific to the code to be released. The scripts scan all files for sensitive content.
Furthermore, the project team should be working with the IT security office to conduct regular code scans (this is both at the application and source code levels). The CTO team works regularly with security and is creating two scripts ([#1](https://github.com/GSA/codeinventory-github) and [#2](https://github.com/GSA/codeinventory)) that project teams can use to scan their code. These scans are different than those done by security, as they are specific to the code to be released. The scripts scan all files for sensitive content.
As with all of these open sourcing tasks, one approach would be to work on open sourcing closed source code on a project by project basis. This could be as an update is planned, as vendors transition, etc. Eventually all projects would become open sourced.

0 comments on commit f33e8aa

Please sign in to comment.