## page was renamed from Software/Assessment/Documentation/UpdateCylcle . '''To Software''' '''[[Software]]''' - '''To Software-Assessment - ''' '''[[Software/Assessment]]''' - '''To [[Software/Assessment/Documentation/EmergencyPatches|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 ==== {{{#!wiki note ''Step1, DevelopmentTools'' subpage ? instructions to create accounts/to connect to bugtracker, github, email mailing list }}} * Link to ''[[Software/Assessment/Documentation/UpdateCycle/step1|Overview: Developers Development Tools]]'' * 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: a. thru their developers branch ['''A'''], a. through github developer branches<
>'''''(needs further documentation)''''', a. by email (preferable as diff), a. by an attachment in the bug-tracker {{{#!wiki note ''by an attached diff (preferred) or updated/replacement file (deprecated) in the bug-tracker'' (BenBE) }}} a. thru other channels . to the Software-Assessment team.<
> * 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: <
> a. Bug number and link to the bugtracker a. short description of the bug / patch a. short description of patch area (what functionality will be changed by the patch) a. 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: 1. A Software-Assessor reviews the patch (2nd review) 1. A Software-Assessor reviews bugtracker documentation a. reviewed by 2 Software-Assessors a. tested by at least 2 software testers 1. 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. 1. 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)''''' {{{#!wiki note 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?" {{{#!wiki note ''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 [[Software/Assessment/Documentation/EmergencyPatches|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-devel'' ||'''C''' ||Software Assessors (read,write) || cacert-devel bug-# || ||production system cvs branch ||''cvs'' ||Critical Sysadmins (on production system) || [[https://www.cacert.org/src-lic.php|www.cacert.org/src-lic.php]] || ||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 [[Software/Assessment/Documentation/EmergencyPatches|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 [[Software/Assessment/Documentation/EmergencyPatches|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 [[Software/Assessment/Documentation/EmergencyPatches|Emergency Patches Process]]''' === Graphical Overview: Repository branches and the Access levels === {{https://svn.cacert.org/CAcert/Software/SoftwareAssessment/Software-Assessment-Project-20100511-1k.jpg}} See also: [[Software/Assessment/20100511-S-A-MiniTOP-telco|Software-Assessment Project meeting 2010-05-11]] === Links === * [[Software/DevelopmentWorkflow|GIT Software Development Workflow (WIP)]] * [[https://svn.cacert.org/CAcert/Software/SoftwareAssessment/Software-Assessment-Project-20100511-1.jpg|Software Assessment Process Cycle 2010-05-11]] ---- . '''Review by''' . 2013-02-26 u60 ---- . CategorySoftware . CategorySoftwareAssessment