BP.01.012 - Business Practice for Source Code Management

Printable Version in PDF Format (Get Adobe Acrobat)

Table of Contents

History [top]

  • Business Practice Number: BP.01.012
  • Version: 1
  • Drafted By: Peter Mosinskis
  • Approved By: Michael Berman
  • Approval Date: 07/12/2016
  • Latest Revision Date:

Purpose [top]

Describes the ITS practice for software source code management

Background [top]

CSU Channel Islands creates and maintains a number of software applications that provide various services to students, faculty, staff, and the community. Timely access to current source code is necessary both while the software is initially being built and throughout its entire useful lifetime as: defects are discovered and must be corrected; new features and functionality are requested by users; changes are made to hardware or infrastructure; questions arise to as to the exact purpose or result of a piece of software. Proper source code management can also reduce effort and increase the reliability of the development process.

Business Practice [top]

Accountability [top]

  • VP for Information Technology Services
  • Director, IT Strategy
  • Director, Enterprise Services and Security
  • Manager, Infrastructure Technology

Applicability [top]

ITS employees who develop software applications. In addition, only source code for software applications that are in (or are expected to be put into) production are covered by this practice.

Definition(s) [top]

  1. Source Code: All files required to compile, build, and test a software application. This includes, but is not limited to: source code files, build scripts, configuration files, project/IDE metafiles, SQL scripts, and presentation files (HTML, CSS, Javascript).
  2. Revision: A source code file as it exists as at a certain point in time. This consists of the base file, as it was created, and all changes made to the file up to that point in time. Each time a new change is made to the file, the revision number will monotonically increase.
  3. Commit: A set of changes to one or more files that will become a revision to each file.
  4. Tag: An identifier given to a commit that is particularly noteworthy. Tags typically correspond to test and production releases of the software. Tags can also be referred to as a “tagged release” or a “version” of the software
  5. Source Code Management (SCM): The process of storing and labeling source code and all revisions to source code
  6. Source Code Management System: A tool for assisting with SCM

Text [top]


A tool can automate a large portion of the SCM process by automatically identifying changes to files and organizing them into revisions and commits. A SCMS provides other benefits to the software development process that would be very costly to do manually, such as providing source code authors with a convenient means to: review revisions to files; review a history of commits to a project; rollback to a particular commit; and work on different features at the same time.

In order for a tool to be useful, developers must make regular use of the tool and decide upon common naming standards such that other developers know where to find the source code they are looking for. 

Use of a Source Code Management System (SCMS) 

Source code files that will be (or are expected to be) put into production shall be stored in a SCMS. Source code used for other purposes (such as training, experimentation, or performing a one-off task) may be stored in the SCMS as desired or necessary, and should be tagged or categorized to indicate such use. 

All source code shall be stored in a SCMS that meets the following requirements:

  1. Available over the internet
  2. Limited only to authorized users
  3. Backed up in accordance with CI’s disaster recovery plans
  4. Automatically tracks changes to files and maintains them as a list of revisions

Each ITS unit may select the most appropriate SCMS which meets these requirements.

Commit Schedule

All changes made to source code shall be submitted to the SCMS within seven (7) business days.

Tagging Releases

All software running in production shall have a corresponding tagged release in the SCMS. The default naming convention for tagged releases shall be to name them after the date that they are created and for the time-stamp on production files to match the tag name. For example, if a project exists on a production server with the timestamp 3-30-2016, the tag “3-30-2016” must exist in the SCMS.

In some cases naming a release after the date may be confusing or impractical. In these cases the production installation shall contain a file called “version.txt” and the contents of this file shall be the name of the tag in the SCMS.

Exhibit(s) [top]

Assessment History [top]



Role Assigned

Annual review of business practice     

 Annual - July  

  VP for ITS