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: developers delivers patches
Step1, DevelopmentTools subpage ? instructions to create accounts/to connect to bugtracker, github, email mailing list
- 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],
through github developer branches
(needs further documentation),- by email (preferable as diff),
- by an attachment in the bug-tracker
by an attached diff (preferred) or updated/replacement file (deprecated) in the bug-tracker (BenBE)
- thru other channels
to the Software-Assessment team.
- Developers send their patches:
- Status of bug in bugtracker switch to "Fix available"
Step 2: First SA review, transfer to testserver repository
- Involved parties: Software-Assessors, Software-Assessment team
- Documentation: Bugtracker
Software-Assessment team reviews the code. At least 2 Software Assessors have to approve the patch and have to document this in the bugtracker.
Status of bug in bugtracker switch to "Needs review & testing"
Step 3: Test scenario deployment
- 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 (Software Testers Portal), 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 includes required infos to the software testers:
- Bug number and link to the bugtracker
- short description of the bug / patch
- short description of patch area (what functionality will be changed by the patch)
- requirements to test the patch (for example: you need several accounts with client- and server-certs, and one test must pe performed with an account having Support-Engineer privileges)
Step 4: Software testing
- 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
- Status of bug in bugtracker switch to "Needs review" if patch testing is complete (tested by at least 2 software testers)
Step 5: Second SA review, transfer to production
- Involved parties: Software-Assessors, (Sysadmins)
- Documentation: Bugtracker, Git
- Action items:
- A Software-Assessor reviews the patch (2nd review)
- A Software-Assessor reviews bugtracker documentation
- reviewed by 2 Software-Assessors
- tested by at least 2 software testers
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, a Software-Assessor 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. Delivery of the diff patch will be send also via cacert-devel mailing list.
Proposal signature? signed email?
(needs further clarification, documentation)Send by signed mail to critical with cc to cacert-devel; CC skipped if private information have to be transferred, with public details disclosed ASAP.
- Status of bug in bugtracker switched to "ready to deploy"
Remark: Second review can be made anytime between step 2 First Review and testing is running
Step 6: Implementing to production
- Involved parties: Sysadmins
- Exceptional strategy: Sysadmins, Software-Assessor, Arbitrator
- Documentation: message to cacert-systemlog at 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
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 [C] (see also cacert-systemlog [cvs.cacert.org checkin notification] messages)
- Status of bug in bugtracker switched to "solved?"
Step6, DeployPatches subpage ? instructions/procedures for critical team?
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).
Details see Emergency Patches Process
Step 7: post work
- Involved parties: Software-Assessor, Test team
- 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.
- Test team updates the software testers portal and transfers the fixed patch to a test finished subpage
Repository branches and the Access levels
Developers branches
A
developers, Software-Assessment team
several
Testserver branch
B
Software-Assessment team (only) (read/write)
cacert-devel
Release candidate branch
single bug# branch out of cacert-develC
Software Assessors (read,write)
cacert-devel bug-#
production system cvs branch
cvs
Critical Sysadmins (on production system)
Production Mirror branch
D
Critical Sysadmins (write), Software Assessors (write), all (read)
cacert
Adhoc SQL queries
- Involved parties: Arbitrator, Software-Assessor, Sysadmin
- Documentation: Arbitrations
- Adhoc SQL queries are probably triggered thru an arbitration process. Documentation will be written within the arbitration case protocol
- The adhoc sql queries 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.
Details see Emergency Patches Process
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.
Details see Emergency Patches Process
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.
Details see Emergency Patches Process
Graphical Overview: Repository branches and the Access levels
See also: Software-Assessment Project meeting 2010-05-11
Links
Review by
- 2013-02-26 u60