To Software Software - To Software-Assessment - Software/Assessment - To Emergency Patches Process
Software Development Update Cycle
This page documents the proposed CAcerts new Software-Assessment Cycle with the new version control system GIT of choice.
This is work in progress
Software Updates, Software patches
- Step 1:
- Involved parties: Developers, (Software-Assessment team)
- Documentation: Bugtracker
First, we have a group of developers ... all are individuals, some may build a team ... The sources they'll get from the main website or the read-only Software-Assessment repository [D], thats a mirror branch from the production system. They can add an individual developers branch [A] on that repository too, not mixed with the other branches. Developers send their patches thru their developers branch [A], by email, by an attachment in the bug-tracker or thru other channels to the Software-Assessment team.
- Involved parties: Software-Assessors, Software-Assessment team
- Documentation: Bugtracker
Software-Assessment team - reviews the test results, and - reviews the code. At least 2 Software Assessors have to approve the patch and have to document this in the bugtracker.
- Step 3:
- Involved parties: Software-Assessors, Software-Assessment team, Test team, Developers
- Documentation: Wiki page, Bugtracker
The Software-Assement team reviews the patches and order them by priority and relevance to add the patch to the test-branch [B] in the repository.
There will be a test entry page in the wiki, showing the current patches that are under testing, with the links to the bugtracker or the overview descriptions. The Software-Assessment team checks also the requirements against the possible addtl. tasks that needs to be performed to prepare the testserver to be ready for testers.
Documentation must include:
- a) what functionality will be changed by the patch
- b) requirements for testing (for example: you need several accounts with client- and server-certs, and one test must pe performed with an account having Support-Engineer privileges)
c) name or IP address of the test system that tests must run against
- Step 4:
- Involved parties: Software-Assessors, Software-Assessment team, Test team, Individuals, Developers
- Documentation: Bugtracker
The testers now starts testing on the testserver with reporting into the related bugtracker entry. The test team is a group of software testers, build from developers and ordinary users from the community that share their experience about used testing tools and scripts. Everyone single report of a successfull test cycle or problem report is welcome. At least two
- Step 5:
- Involved parties: Software-Assessors, (Sysadmins)
- Documentation: Bugtracker, Git
Software-Assessors bundle the tested patches to a release candidate in the release candidate branch [C] of the repository. At this step, there can be an addtl. test phase for the installation procedure and recovery procedure. This will be documented also in the bugtracker.
If once bundled, they'll send / transfer the release candidate bundle to the critical sysadmin team with further instructions how to install the patch and a informations for a fallback strategy. This will be documented also in the bugtracker
- Step 6:
- Involved parties: Sysadmins
- Exceptional strategy: Sysadmins, Software-Assessor, Arbitrator
Documentation: message to cacert-systemlog@lists.cacert.org
- Sysadmin team installs the release candidate on the production system. If there are some problems, they follow the fallback strategy.
- Documentation of install procedure: in the bugtracker
- Involved parties: Sysadmins
The changes will be automatically synchronized to the repository within the production system. Sysadmin team triggers a push replication of that repository to the mirror repository on the Software-Assessment repository [D].
- Exception:
- If the fallback strategy doesn't solve the problem, and the sysadmin team cannot solve the problem alone, they can get assistance from the Software-Assessment team by giving one named Software-Assessor (related to the discussion - here the name 'Application Engineer' can be set) access to the production system thru a controlled remote session. This needs to be arbitrated later on (documentation of this process thru an arbitration case).
- Step 7:
- Involved parties: Software-Assessor
- Documentation: Wiki page, Bugtracker
Software-Assessment team verifys the installation of the release candidate by comparing the 2 repository branches [C] (release candidate) and production-system-mirror [D]. and document the result in the bugtracker.
Repository branches and the Access levels
Developers branches
A
developers, Software-Assessment team
Testserver branch
B
Software-Assessment team (only) (read/write)
Release candidate branch
C
Software Assessors (read,write)
production system cvs branch
cvs
Critical Sysadmins (on production system)
Production Mirror branch
D
Critical Sysadmins (write), all (read)
Adhoc SQL querys
- Involved parties: Arbitrator, Software-Assessor, Sysadmin
- Documentation: Arbitrations
- Adhoc SQL querys are probably triggered thru an arbitration process. Documentation will be written within the arbitration case protocol
- The adhoc sql querys will be prepared/reviewed (and) tested by the Software-Assessment team in above step 5 and have to be transfered to the sysadmins. The sysadmin team executes the sql query against the production system.
Emergency Patches
- Involved parties: (Developer), Software-Assessor, Sysadmin
- Documentation: Wiki page, Bugtracker
Emergency patches follows the path described in the "Software Updates, Software patches" section, except the bundling hasn't to wait for the running test patches. The emergency patch has to be tested individualy bundled individualy, and transfered as an emergency patch to the sysadmins on the production system. The changes have to be incorporated from the mirror repository [D] later on to the testsystem.
OS Updates
- Involved parties: Sysadmins
- Documentation: Wiki page, Bugtracker
- OS Updates can be tested on the testservers. With the installation procedure the updates can be applied onto the production system by the Critical sysadmins
- As Testserver system environment should be as comparable to the production system environment, the testing of OS updates on the testserver follows the Software Update Cycle management, first test updates on a testserver, then apply on the production system.
Graphical Overview: Repository branches and the Access levels
See also: Software-Assessment Project meeting 2010-05-11
Links
