Branches and Updates
Supported in this case means we will provide useful tools to accomplish the most common and/or basic requirements for Linux systems on campus. We will maintain these tools, making sure they stay up to date be responsive to breaking changes.
Currently there are 3 environments, or branches, that we maintain.
- “production” will contain code that is tested and functional. It will be the current standard for stable code.
- “ncsutest” will be the next in line. It is where we will place the next round of updated modules and tooling for testing. It will change more frequently than production and may at times contain broken code. It will be rolled into production on a predictable schedule. For more details see [#change-management].
- “foreglatest” is a branch that is automatically updated with the latest forge modules. It will change rapidly and may frequently break. It is useful for testing code against the latest puppet module versions.
Change Management Workflow
Updates to production will be rolled out quarterly. These updates may be simple updates to the upstream modules we use, or they may be changes to the modules provided in ncsu::. Sometimes there may be features added as well. The changes will be made available in ncsutest for anybody that wants to experiment.
- 60 days out from the update we will begin to apply new upstream module versions and roll out ncsu:: module updates.
- 30 days prior to roll out changes will be frozen so everybody has time to test against the new changes.
Scheduling and Communication
The exact dates will vary as we work around events on the Academic Calendar, but each stage will be announced via SysNews, the NAG, our own ELS mailing lists. You can also view the OIT Linux Services calendar here:
At each 60, 30, and 0 day event an email will be sent to the NAG, SysNews, and the OIT Linux mailing list to remind everybody.
Should a blocker be found during this 30 day window that update can be blocked for 1 cycle but will go through in the following quarter. This ensures that all modules stay up to date but also gives some flexibility for admins to make any changes necessary in their code.
This process is quite necessary, as the rate of changes made to the upstream module library is high. Without constant monitoring it is easy to fall behind. There are dependencies between the modules that must be maintained, meaning an update of one module may require the update of several others. Often these updates have breaking changes that will require changes to our local modules. CSI will ensure that the modules in ncsu:: are updated and ready to use these new versions each quarter. It will be the responsibility of the admins to update their own modules, although they also have the option of forking the ncsu:: code and staying with certain versions as needed.
Working Outside the Change Window
Due to the use of git branches as Puppet environments it is very easy to an individual to maintain their own “production” branch with whatever changes from official production they need. For example, if you need to add a module but don’t want to wait for the next change cycle to use it, simply make a branch off of production and put the changes there. Any box in that branch will get the updated module and it won’t disturb anything else.
Getting Changes into Production
Only the ncsutest branch will be merged into production. All changes destined for production must be merged into ncsutest and pass all QA testing by the end of the quarterly update period. Between the 60 and 30 day mark from the quarterly merge you can create a pull request to have your code changes merged into ncsutest.Edit me