Development and deploy procedures ver. 1.0 Addition / ITU / Cohaesio Addition extends document ”gemini resolutions in a 3 server setup environement” ver. 2.0

BACKGROUND PRINCIPALS  RELEASES –Issues are resolved in bundles (builds) using versioning. –A build is defined prior to starting development –The build is being addressed as a collective whole throughout the release cycle –Testing on DEV servers are focused to address if the solution solves the reported issue. DEV servers will never be stable nor predictable. –In the deploy proces to Cohaesio servers, all will either succeed or all will fail  DEPLOYS –The deploy process is strenghtened by inserting flightchecks in the process –The QA a server is being considered as a testground for deploy to production –Deploys to Coheasio servers will be handled by Cohaesio. –The timeline for a deploy is variable, it can be set based on number of issues or by requested calendar date –ITU’s own development can overtake any time in the deploy proces.

Server environments setup Addition Dev env Cohaesio QA env Cohaesio Prod env Addition dev environment is the projects construction site and sandbox environment. Here solutions for issues are developed and their functional implementation is discussed with + verified by the productowner. An approved solution gets packed and made ready to deploy to QA and ultimately production The purpose of the QA environment is to verify that a completed build can be reproduced 1:1 on the QA and without obvious side-effects to the rest of the website. When the installation has been verified by the product owner as a reproduction from development, the procedure is repeated finally on production

Overall proces illustration R1 BUILD DEFINITION DEVELPOPMENT PROCESS QUALITY ASS. DEPLOY TO QA QUALITY ASS. DEPLOY TO PROD QUALITY ASS. CLOSURE R2 BUILD DEFINITION DEVELPOPMENT PROCESS QUALITY ASS. DEPLOY TO QA QUALITY ASS. DEPLOY TO PROD QUALITY ASS. CLOSURE

 Step 1: Identify issues to include in build –Issues are identified in Gemini by ITU and assigned to the build.  Step 2: Evaluate build issues –Developers will evaluate the issues intended for the build Is there a need for further clarification? Are issues otherwise relevant for the build not included? Are there Sitecore bugs we can’t fix? Is the problem relevant for both CMS and SIP installation? Etc –Developers plan and estimate the build as a collective whole Approval of individual estimates Indiciation of date for commencing deploy cycle –When all is clear, Development can begin DEVELOPMENT process – early phase Slide 5

 Step 3: Commence development on addition DEVsandbox environment. –Focus is on adressing the reported problem and verifying that the proposed solution will also solve the problem to a satisfactory level –Issue dialouge will be ongoing as per need –Being a sandbox environment, solution stability is not to be expected to a far degree  Step 4: Issue approval –Issue is updated with testspecification + relevant information, fx if actual content is part of solution –Issue is assigned to ITU for final approval of solution –Cohaesio is informed of up-coming deploy DEVELOPMENT process Slide 6

 Step 1: Deploy packages –Deploy packages with instructions are send to Cohaesio  Step 2: Deploy verification (Addition) –Issue verification each issue is verified to be working as expected –System stability Build verification test is performed (functional) Regression test (not mature to be applied yet) Flightcheck is performed (visual) –Changes made as part of verification are undone  Step 3: Deploy approval –Build are assigned to ITU for own testing Deploy to QA process – the deploy Slide 7

 If the build is verified by both Addition and ITU –Update deploy packages for production System variables (fx web.config) Content if needed (especially content) Other updates Deploy to QA process - approval Slide 8

 If the deploy verification for some reason fails –Identification and analysis of problem (why did the build fail?) Unwholesome development –Is the wanted aspect tolerable to be addressed in separate issue? –Is the wanted aspect enough to reject the build? Unexpected problem occurred –Is the error tolerable? –Is the error strong enough to reject the build? –Add corrections to dev (test and approve as needed) and update deploy package with fix –Roll back QA –Redo deploy Deploy to QA process - rejection Slide 9

 Step 1: Deploy packages –Deploy packages with instructions are send to Cohaesio  Step 2: Deploy verification (Addition) –System stability Build verification test is performed (functional) Flightcheck is performed (visual) –Changes made as part of verification are undone  Step 3: Deploy approval –Build are assigned to ITU for own testing Deploy to PROD process – the deploy Slide 10

 If the build is verified by both Addition and ITU –Update Gemini with appropriate resolutions –Update log of custom functionality (in progress) –Close issues Deploy to PROD process - approval Slide 11

 If the deploy verification for some reason fails –Immediate rollback to previous state –Evaluation and analysis of problem (why did the build fail?) –Update deploy package with fix –Redo deploy Deploy to PROD process - rejection Slide 12

 Notes There is no point in performing system stability test on DEV server, as it will only tell us what we already know. That the DEV server is slow, unstable and ever changing as it’s a host for new development. There is little gain in performing issue verification test on production server. The main concern should be the big picture, ot make sure no unexpected sideeffects from QA to prod have appeared  Next step –Over the course of R1 and R2: To refine the build verification test To refine the flightcheck To continue establishing regression tests procedures To evaluate the overall cycle procedure Notes and next step Slide 13