CMS (Publishing System) Change and Release Management Plan

Transcription

1 CMS (Publishing System) Change and Release Management Plan February 19, 2009 Version 1.1

2 Table of Contents 1. OBJECTIVES 1 2. SCOPE Project Tracking & Version Control Tools 1 3. GLOSSARY 2 4. CURRENT CHANGE CONTROL PROCESS Current Development Responsibility Matrix Current Build & Deployment Responsibility Matrix Current CMA, CDA Core & CMA Front-End (FLEX) Change Control Current Template & Front-End File Change Control Current Base & Title-Specific Content Type Change Control PROPOSED CHANGE CONTROL PROCESS Improving CMS Change Management Process Implement Formal Change Control Board Define Roles & Responsibilities Create New Tools Improve Communication Improve Build & Deployment Procedures Proposed Development Responsibility Matrix Proposed Build & Deployment Responsibility Matrix Proposed CMA Change Control Proposed CMA Front-End (FLEX) Change Control Proposed CDA Core Change Control Proposed Template & Front-End File Change Control Proposed Base & Title-Specific Content Type Change Control How Do We Get Here? Tools Currently In Use Work in Progress Proposed for Future Use 22 APPENDIX A: QA CMA & CMA FRONT-END (FLEX) BUILD RUN PROCEDURES 23 APPENDIX B: QA CMA & CMA FRONT-END (FLEX) DEPLOYMENT RUN PROCEDURES 24 APPENDIX C: PROD CMA & CMA FRONT-END (FLEX) BUILD & DEPLOYMENT RUN PROCEDURES 27 APPENDIX D: CDA CORE BUILD RUN PROCEDURES 28 APPENDIX E: CDA CORE DEPLOYMENT RUN PROCEDURES 30 Table of Contents, cont. Page ii 02/19/09

3 APPENDIX F: PROD CDA CORE BUILD & DEPLOYMENT RUN PROCEDURES 33 APPENDIX G: TEMPLATE & FRONT-END FILE BUILD RUN PROCEDURES 34 APPENDIX H: TEMPLATE & FRONT-END FILE DEPLOYMENT RUN PROCEDURES 36 APPENDIX I: PROD TEMPLATE & FRONT-END FILE BUILD & DEPLOYMENT RUN PROCEDURES 37 APPENDIX J: BASE & TITLE-SPECIFIC CONTENT TYPE CHANGE BUILD & DEPLOYMENT PROCEDURES 38 Page iii 02/19/09

4 1. OBJECTIVES This document details the current and future Change Release Management procedures for the ongoing CMS initiative. 2. SCOPE Presented within are high level workflow diagrams mapping out both team interactions and dependencies as changes advance through affected environments, as well as detailed procedures defining change implementation. The target audience for this plan consists of key CMS stakeholders and team members, e.g., Architecture, Application Support, Quality Assurance, Web Operations, Title and Front-End Development. 2.1 Project Tracking & Version Control Tools Source control, project tracking and issue tracking for CMS Core and Title-specific projects are managed using Collabnet, a distributed knowledge management platform that incorporates Subversion, an open source version control system, which serves as the repository for related source code. RMS (Request Management System) is used to facilitate communication among various teams in order to action deployment tasks. Workflow documents specify where Collabnet or RMS is to be used. Collabnet RMS IT Application Support Page 1 02/19/09

5 3. GLOSSARY Terms Admin Tool Build Build Repository CCB CDA Checksum CM CMA CMA Front-End CollabNet CSS FLEX JS MXML Definition The CMS Admin Tool allows registered users to perform administrative functions, defining and editing the following: Web-based Structure: incorporating Publications, Channels, Content Types, Option Lists, Templates Security: creating user accounts in CMS, defining roles and permissions for users, and grouping users by their roles Publishing: master processes for pushing published content to customerfacing environments Tools: reporting, file management, and cleaning or publishing switches for publications In the software industry, this term refers to the compilation process during which source code files are converted into executable code. A gateway application that secures CMA-based tools in all environments; allows authorized members of the CMS Team to easily retrieve stored files for deployment in QA and Production; also serves as repository for roll-back to previous versions. Change Control Board Content Delivery Application: CMS component that allows rendering and pre-caching of all published content; resides on the CMA and the Extreme Rendering Engine. A checksum or hash sum is a fixed-sized datum computed from an arbitrary block of digital data for the purpose of detecting accidental errors that may have been introduced during its transmission or storage. Configuration Management or Change Management Content Management Application: CMS component that allows editors to edit and preview their content in the CMS system, as well as connect to the web interface via http request. CMS editorial interface; the FLEX component of UI in the system. Knowledge management platform that provides workflow coordination technology to support globally distributed teams; also incorporates Subversion, an open source, version control and Software Configuration Management (SCM) system. Cascading Style Sheets: A stylesheet language most typically used to define a single library of styles that are used over and over throughout a large number of related documents, as in a web site. A CSS file might specify that all numbered lists are to appear in italics. By changing that single specification, one can quickly and easily update the look of a large number of documents. Adobe Flex is an open source framework for building and maintaining expressive web applications that deploy consistently on all major browsers, desktops, and operating systems; the CMS Admin Tool is currently a FLEX interface, but will ultimately be HTML-based. The CMS CMA Front-End is a FLEX interface. JavaScript: a scripting language widely used for client-side web development. The XML-based user interface markup language used by the FLEX-based CMA Front- End for client-server communication. IT Application Support Page 2 02/19/09

6 Terms Definition QA Release Release Manager Quality Assurance The distribution (either public or private) of an initial or upgraded version of a software product. Coordinates schedules and builds; serves as a liaison among various business units to guarantee smooth and timely delivery of software products or updates. Request State Emergency: A severity level classification indicating that the infrastructure or application requires an immediate fix, bypassing the change control process temporarily; being in or verging on a state of crisis or emergency with very broad customer impact. Normal: A severity level classification indicating that there is a lack of functionality for a minor portion of the infrastructure or application with very limited impact to customers. RMS Rollback Saxon SWF Subversion CMS CMS UI Tomcat WAR File WebDAV Request Management System A procedure that allows committed changes and updates to be returned to the previous state. The SAXON package is a collection of tools for processing XSLT documents and is currently used by the Architecture Team to build customized tools that query or parse the CMS CRX Repository. Shockwave Flash file (.swf); a playable Macromedia Flash animation, which can be referred to as a swiff ; used as a standalone Flash web site or as an element, such as an animated logo or intro. An open source, version control and SCM system, which serves as repository for CMSrelated source code. Publishing System: allows content to be edited, previewed and published on the web; designed to replace the V5 and V6 Content Tools, as well as the entire Vignette Content Management and Content Delivery System. The CMS User Interface: an intuitive user interface built to be editor-friendly, easy to learn and use. Provides a pure Java HTTP web server environment to run Java code; developed by the Apache Software Foundation (ASF). (WAR is short for Web ARchive.) A JAR file format used to distribute a collection of files that together constitute a Web application. An interface (IETF standard, RFC 4918) to the JCR (implemented by Day) that allows the CMS Team to store and retrieve files; most notably, the team uses WebDAV to store templates, configuration files and XSLT style sheets, so that they can retrieve them when rendering or transforming a content item. XRE XSLT Extreme Rendering Engine: CMS component that renders content published within the CMS CMA. XSL Transformations: part of the Extensible Stylesheet Language (XSL) family; CMS IT Application Support Page 3 02/19/09

7 Terms Definition XSLT templates developed by the Title Tech Leads are used by the CMS CDA Core to transform content stored within CRX into other formats, such as HTML. IT Application Support Page 4 02/19/09

8 4. CURRENT CHANGE CONTROL PROCESS This section outlines the Build, Deploy and Change Control procedures currently in place for CMS. See Section 5 for detailed recommendations on improving and streamlining these procedures as CMS and its supporting tools and applications mature. 4.1 Current Development Responsibility Matrix CMA Category CMA Front-End (FLEX) CDA Core Base Content Type Title-Specific Content Type Templates Front-End Files Responsibilities Architecture Team is responsible for JAVA Code. FLEX Team is responsible for MXML and SWF. Architecture Team is responsible for JAVA Code and XSLT Core. Title Dev Team requests Base Content Type changes; Architecture Team approves and then makes these changes. Architecture Team approves Title-Specific Content Type change requests; Title Dev Team then makes these changes. Title Development Team is responsible for XSLT and XML. Front-End Development Team is responsible for CSS and JS. 4.2 Current Build & Deployment Responsibility Matrix Type of Build Request QA Build QA Deployment & Script Execution PROD Deployment & Script Execution CMA Architecture Lead Architecture Lead Web Ops Engineer CMA Front-End (FLEX) Flex Lead Architecture Lead Web Ops Engineer CDA Core Architecture Lead Architecture Lead Web Ops Engineer Content Type (Base & Title- Specific) Architecture Lead Architecture Lead Architecture Lead Templates Title Tech Lead Title Tech Lead Web Ops Engineer Front-End Files Title Tech Lead Title Tech Lead Web Ops Engineer IT Application Support Page 5 02/19/09

9 4.3 Current CMA, CDA Core & CMA Front-End (FLEX) Change Control The diagram below defines the workflow to be used for the build and deployment of Core CMA, CMS UI, Admin Tool, CDA Core, WebDAV, Preview, and XRE components, including testing and communications. Hyperlinked Diagram is available: FLEX_CM_Today_Workflow_files/CMS_CMA-CDA-FLEX_CM_Today_Workflow_frames.htm?revision=66 QA Build Procedure, CMA & CMA Front-End (FLEX): Defines how to build components for both the CMA and CMA Front-End (FLEX). Please see APPENDIX A: QA CMA & CMA FRONT-END (FLEX) BUILD for the detailed run procedure. QA Deployment Procedure, CMA & CMA Front-End (FLEX): Defines how to deploy components for both the CMA and CMA Front-End (FLEX). Please see APPENDIX B: QA CMA & CMA FRONT-END (FLEX) DEPLOYMENT for the detailed run procedure. PROD Build & Deployment Procedure, CMA & CMA Front-End (FLEX): Defines the operational tasks for CMA & CMA Front-End builds and deployments to IT Application Support Page 6 02/19/09

10 PROD. Please see APPENDIX C: PROD CMA & CMA FRONT-END (FLEX) BUILD & DEPLOYMENT for the detailed run procedure. QA Build Procedure, CDA Core: Defines how to build components for CDA Core. Please see APPENDIX D: CDA CORE BUILD for the detailed run procedure. QA Deployment Procedure, CDA Core: Defines how to deploy components for CDA Core. Please see APPENDIX E: CDA CORE DEPLOYMENT for the detailed run procedure. PROD Build & Deployment Procedure, CDA Core: Defines the operational tasks for CDA Core builds and deployments to PROD. Please see APPENDIX F: PROD CDA CORE BUILD & DEPLOYMENT for the detailed run procedure. IT Application Support Page 7 02/19/09

11 4.4 Current Template & Front-End File Change Control The following diagram defines the workflow to be used when checking out, packaging and deploying both XSLT Templates and Front-End Static Files (e.g., JPEG, PNG, CSS, and JS). Prerequisites for packaging and deployment are also addressed. Hyperlinked Diagram is available: File_CM_Today_frames.htm?revision=48 QA Build Procedure, Templates & Front-End Files: Defines how to build components for both Templates and Front-End Files. Please see APPENDIX G: TEMPLATE & FRONT-END FILE BUILD for the detailed run procedure. QA Deployment Procedure, Templates & Front-End Files: Defines how to deploy components for both Templates and Front-End Files. Please see APPENDIX H: TEMPLATE & FRONT-END FILE DEPLOYMENT for the detailed run procedure. IT Application Support Page 8 02/19/09

12 PROD Build and Deployment Procedure, Templates & Front-End Files: Defines the operational tasks for Template & Front-End File builds and deployments to PROD. Please see APPENDIX I: PROD TEMPLATE & FRONT-END FILE BUILD & DEPLOYMENT for the detailed run procedure. IT Application Support Page 9 02/19/09

13 4.5 Current Base & Title-Specific Content Type Change Control This process includes Base and Title-Specific Content Type changes. Base Content Type Changes are controlled by the Architecture Team. Title-Specific Content Type changes are controlled by the Title Tech Leads. QA & PROD Build and Deployment Procedure, Base & Title-Specific Content Type Changes: Defines the requirements for Base and Title-Specific Content Type Change builds and deployments to QA and PROD. Please see APPENDIX J: BASE & TITLE-SPECIFIC CONTENT TYPE CHANGE BUILD & DEPLOYMENT PROCEDURES for requirement details. IT Application Support Page 10 02/19/09

14 5. PROPOSED CHANGE CONTROL PROCESS While the previous section defines the current CMS Change Management process, the corresponding applications, tools and procedures are still in the process of maturing. This section presents the proposed CMS Core Change Management process, drafted as a result of the joint effort among key stakeholders and team members (Release Management Working Group) to define a streamlined, robust and efficient release process. IT Application Support Page 11 02/19/09

15 5.1 Improving CMS Change Management Process Recommendations and proposed best practices drafted by the Release Management Working Group follow for the purpose of improving the CMS Change Management Process Implement Formal Change Control Board An internal change control board (CCB) will be formed. o o Will chair meetings for review and approval of CMA, CMA Front-End (FLEX) and CDA Core changes. Will chair meetings for review and approval of Content Type changes. CCB review will not be required for Title Template or Front-End File changes, unless site-wide mass rendering or mass publishing is involved. Project Managers and Title Tech Leads will participate in CCB meetings, as appropriate Define Roles & Responsibilities Development teams will be required to prepare Deployment and/or Release notes to be added to RMS tickets. Title Tech Leads will be responsible for collecting information regarding Front-End File changes, as well as coordinating changes with the Release Manager and Deployment Team. The Release Manager will be responsible for coordinating and consolidating all approved change requests into a single change request Create New Tools Scripts are needed for the execution of various builds, deployments, renderings, mass publishings, etc. o All scripts will be stored in Subversion Improve Communication Title-specific build scripts will be maintained under each Title s Subversion project structure. Changes will be classified as either Normal or Emergency. o To mitigate the risk of outages, rollbacks are to be carried out by deploying the previous version or revision of the deployed WAR file. Formal IT Change Management requests will be required for deployment of major changes. Formal IT site notices will be sent to the client base, as required. IT Application Support Page 12 02/19/09

16 5.1.5 Improve Build & Deployment Procedures A new Spare or QA integration test box will be provided for testing CMA, CDA Core, and CMA Front-End (FLEX) changes before deployment into DEV, QA or PROD environment. QA team will verify or approve CMA, CDA Core, and CMA Front-End (FLEX) changes in Spare or QA integration test box. Deployment to Spare or QA integration test box will be handled by Architecture team. A Build Repository will be implemented for controlling all deployments. o WAR/ZIP/TAR files, along with their checksums, will be archived in the Build Repository for Web Ops Engineers to access or deploy into QA and PROD servers. Requests for deployment into QA and PROD will be made via RMS and carried out by Web Ops. o Deployment form within RMS ticket will be populated with requisite details. 5.2 Proposed Development Responsibility Matrix Category CMA CMA Front-End (FLEX) CDA Core Base Content Type Title-Specific Content Type Templates Front-End Files Responsibilities Architecture Team to be responsible for JAVA Code. FLEX Team to be responsible for MXML and SWF. Architecture Team to be responsible for JAVA Code and XSLT Core. Title Dev Team to request Base Content Type changes; Architecture Team to approve and then make these changes. Architecture Team to approve Title-Specific Content Type change requests; Title Dev Team to make these changes. Title Development Team to be responsible for XSLT and XML. Front-End Development Team to be responsible for CSS and JS. IT Application Support Page 13 02/19/09

17 5.3 Proposed Build & Deployment Responsibility Matrix Type of Build Request CMA CMA Front-End (FLEX) CDA Core Base Content Type Title-Specific Content Type QA Build Architecture Lead QA Deployment & Script Execution Web Ops Engineer PROD Deployment & Script Execution Web Ops Engineer FLEX Lead Web Ops Engineer Web Ops Engineer Architecture Lead Architecture Lead Web Ops Engineer Application Support Web Ops Engineer Application Support Title Tech Lead Application Support Application Support Templates Title Tech Lead Web Ops Engineer Web Ops Engineer Front-End Files Title Tech Lead Web Ops Engineer Web Ops Engineer Team Members CCB Release Manager Responsibilities Will analyze and approve CMS changes. Will coordinate and schedule builds. IT Application Support Page 14 02/19/09

18 5.4 Proposed CMA Change Control This process defines the workflow to be used for the build and deployment of Core CMA components. CMA Build & Deployment Procedures [Note: Run procedures for the proposed CMA change release life cycle will be provided here once they ve been finalized.] IT Application Support Page 15 02/19/09

19 5.5 Proposed CMA Front-End (FLEX) Change Control This process defines the workflow to be used for the build and deployment of CMA Front-End (FLEX). CMA Front-End (FLEX) Build & Deployment Procedures [Note: Run procedures for the proposed CMA Front-End (FLEX) change release life cycle will be provided here once they ve been finalized.] IT Application Support Page 16 02/19/09

20 5.6 Proposed CDA Core Change Control This process defines the workflow to be used for the build and deployment of CDA Core, WebDAV, Preview, and XRE components. CDA Core Build & Deployment Procedures [Note: Run procedures for the proposed CDA Core change release life cycle will be provided here once they ve been finalized.] IT Application Support Page 17 02/19/09

21 5.7 Proposed Template & Front-End File Change Control This process defines the workflow to be used for checking out XSLT Templates and Front-End Static Files (e.g., JPEG, PNG, CSS, JS) in order to package and deploy them. Prerequisites for packaging and deployment are also addressed. Template & Front-End File Build & Deployment Procedures [Note: Run procedures for the proposed Template & Front-End File change release life cycle will be provided here once they ve been finalized.] IT Application Support Page 18 02/19/09

22 5.8 Proposed Base & Title-Specific Content Type Change Control This process defines the workflow to be used for Base and Title-Specific Content Type changes. Base Content Type changes are to be approved and executed by the Architecture Team; Title-Specific Content Type changes are to be approved by the Architecture Team and executed by the Title Tech Leads. Base & Title-Specific Content Type Change Build & Deployment Procedures [Note: Run procedures for the proposed Base & Title-Specific Content Type change release life cycle will be provided here once they ve been finalized.] IT Application Support Page 19 02/19/09

23 5.9 How Do We Get Here? Form a CMS Change Control Board to analyze and approve CMS changes. Establish a Build Repository" to store WAR/ZIP/TAR files in a controlled environment, allowing easy retrieval of files (with proper authentication). Implement a separate Spare/QA test environment that will allow QA to perform integration testing before changes affect DEV/QA/PROD servers. Fine-tune rollback procedure by implementing new tools and processes to roll back gracefully to previous versions and offset deployment failures. Update Build and Deployment scripts to allow integration of test and rollback builds. Integrate CollabNet with RMS for better information flow and traceability. (Note: Feasibility Study is underway.) Provide formal training on the CMS release process to all stakeholders (with an emphasis on Template Developers). IT Application Support Page 20 02/19/09

24 6. Tools 6.1 Currently In Use Tools currently used to facilitate CMS Content and Template delivery to QA or PROD are listed below: Content Item Deletion Tool Content Type Synchronization Tool Content Type Move Channel Tool Content Item Mass Preview Tool Template & Front-End File Mass Rendering Tool Template & Front-End File Mass Publish Tool Data Import Tool Data Export (Data Migration) Tool CMS Title-Specific Admin Tool Redirect Generator Tool Bulk User Creation Tool IT Application Support Page 21 02/19/09

25 6.2 Work in Progress Tools Admin Tool (Web Interface) Build & Deployment Tool (Web Interface) Bulk Delete Tool (Saxon) Bulk Expire Tool (Saxon) Bulk User Load Tool (Saxon) Channel Mover Tool (Web Service) Content Explorer Tool (Web Interface) Content Item Synchronization Tool (Web Service) Continuous Integration Tool (Web Interface) Import Rest Layer Tool (Web Interface) Mass Preview Tool (Web Service) Mass Publish Tool (Web Service) Mass Render Tool (Web Service) Rest Layer Tool (Web Interface) Team Responsible Architecture/Application Support Architecture Architecture Architecture Architecture Architecture Architecture Architecture Architecture Architecture Architecture Architecture Architecture Architecture 6.3 Proposed for Future Use Content Type Comparison Tool Complete Publish Requests Tool (Web Interface) Template Deployment Tool (Web Interface) CMS Tagging Loader Tool Publishing Error Report Tool (Web Interface) Publishing Statistics Tool (Web Interface) Pending Publishing Requests Tool (Web Interface) IT Application Support Page 22 02/19/09

26 APPENDIX A: QA CMA & CMA FRONT-END (FLEX) BUILD RUN PROCEDURES Back-End CMA 1. $ ssh <tcatuserid>@<hostname> e.g., ssh tcat3@qa-cms2.net 2. $ cd ~/sources/cms-cma Go to sources directory 3. $ svn up Update source from Subversion 4. $ ant Run ant to start build process 5. cd ~/build/cms-cma/dist/ Determine if CMS_cma.war and CMS_cma.jar files exist by checking specified directory Front-End CMS UI 1. $ ssh <tcatuserid>@<hostname> e.g., ssh tcat3@qa-cms2.net 2. $ cd ~/sources/cms2.0_gui Go to sources directory 3. $ svn up Update source from Subversion 4. $ ant Run ant to start build process 5. $ ls -ltr ~/sources/cms2.0_gui/deploy Check time stamps of files in folder to determine if successful Front-End Admin Tool UI 1. $ ssh <tcatuserid>@<hostname> e.g., ssh tcat3@qa-cms2.net 2. $ cd ~/sources/cma_admin Go to sources directory 3. $ svn up Update source from Subversion 4. $ ant Run ant to start build process 5. $ ls -ltr ~/sources/cma_admin/deploy Check time stamps of files in folder to determine if successful IT Application Support Page 23 02/19/09

27 APPENDIX B: QA CMA & CMA FRONT-END (FLEX) DEPLOYMENT RUN PROCEDURES Back-End Changes [ssh ing is performed for the appropriate CMS QA Server] 1. $ ps ef grep <tcatuserid> Find relevant tomcat process id e.g., $ ps -ef grep tcat3 2. $ kill <process id> Stop tomcat 3. Backup old war files: cd ~tcat3/base-cms/webapps mv CMS_cma.war./archive/CMS_cma_<current_date>.war mv CMS-cma-admin.war./archive/CMScma-admin-<current_date>.war 4. $ cd ~/base-cms/webapps $ rm rf CMS_cma $ rm CMS_cma.war $ cp ~/source/cms-cma/dist/cms_cma.war. CMS UI [FLEX changes] Do not use kill -9 You can also try: ~tcat3/basecms3/bin/shutdown.s h (however, you should verify that the process actually died) Not mandatory for DEV/QA Remove directories generated by war files and copy the latest war files from the build 1. $ ps ef grep <tcatuserid> Find relevant tomcat process id e.g., $ ps -ef grep tcat3 ) 2. $ kill <process id> Stop tomcat 3. $ cd ~/base- CMS/webapps/ROOT/CMS/CMS2 Do not use kill -9 You can also try: ~tcat3/basecms3/bin/shutdown.s h (however, you should verify that the process actually died) Clean up existing files and copy the latest files from the build IT Application Support Page 24 02/19/09

28 $ rm rf * $ cp -r ~/source/cms2.0_gui/deploy/. 4. $ vi assets/xml/cmsinit Edit CMSInit file 5. <HTTPServices> <HTTPService id="loginhttpservice" url=" login.xml" showbusycursor="true" method="post" /> <HTTPService id="logouthttpservice" url=" logout.xml" showbusycursor="true" method="post" /> </HTTPServices> 6. Save the file :wq Admin Tool UI Comment out HTTPServices xml containing localhost Uncomment out HTTPServices xml containing qa-cms2 and update hostname in the URL value accordingly 1. $ ps ef grep <tcatuserid> Find relevant tomcat process id e.g., $ ps -ef grep tcat3 2. $ kill <process id> Stop tomcat 3. $ cd ~/base- CMS/webapps/ROOT/CMS/admin $ rm rf * $ cp -r ~/source/cma_admin/deploy/. Do not use kill -9 You can also try: ~tcat3/basecms3/bin/shutdown.s h (however, you should verify that the process actually died) Clean up existing files and copy the latest files from the build 4. $ vi index.html Edit index.html file 5. Search for localhost and replace with IT Application Support Page 25 02/19/09

29 Start Tomcat 1. cd ~tcat3/base-cms/bin/;./startup.sh Start tomcat 2. Check latest log file in ~/base-cms/logs/ Sanity Test Determine if you can log into CMS UI: 1. Log into CMS: 2. Open existing / create new / preview content. 3. Verify proper functioning of CMA, CMA Front- End and CDA Core. Rollback 1. Deploy previous WAR file. IT Application Support Page 26 02/19/09

30 APPENDIX C: PROD CMA & CMA FRONT-END (FLEX) BUILD & DEPLOYMENT RUN PROCEDURES For detailed instructions on the operational tasks involved in PROD builds and deployments, see the CollabNet documentation repository: IT Application Support Page 27 02/19/09

31 APPENDIX D: CDA CORE BUILD RUN PROCEDURES Note: Typical CDA builds are for CDA Core only. (Other build types are performed upon special request.) CDA Core 1. $ ssh <tcatuserid>@<hostname> e.g., ssh tcat3@qa-cms2.net 2. $ cd ~/sources/cms-cda Go to sources directory 3. $ svn up Update source from Subversion 4. $ ant Run ant to start build process 5. cd ~/build/cms-cda/dist/ Determine if rest.war file exists by checking specified directory WebDAV 1. $ ssh <tcatuserid>@<hostname> e.g., ssh tcat3@qa-cms2.net 2. $ cd ~/sources/cms-webdav Go to sources directory 3. $ svn up Update source from Subversion 4. $ ant Run ant to start build process 5. $ cd ~/build/cms-webdav/dist/ Determine if webdav.war file exists by checking specified directory Preview 1. $ ssh <tcatuserid>@<hostname> e.g., ssh tcat3@qa-cms2.net 2. $ cd ~/sources/cms-preview Go to sources directory 3. $ svn up Update source from Subversion 4. $ ant Run ant to start build process 5. $ cd ~/build/cms-preview/dist/ Determine if preview.war file exists by checking specified directory XRE 1. $ ssh <tcatuserid>@<hostname> e.g., ssh tcat3@qa-cms2.net 2. $ cd ~/sources/xre Go to sources directory 3. $ svn up Update source from Subversion IT Application Support Page 28 02/19/09

32 4. $ ant Run ant to start build process 5. $ cd ~/build/xre/dist/ Determine if xre.war file exists by checking specified directory IT Application Support Page 29 02/19/09

33 APPENDIX E: CDA CORE DEPLOYMENT RUN PROCEDURES Note: Typical CDA deployments are for Core CDA only. (Other deployment types are performed upon special request.) CDA CORE 1. $ ps ef grep <tcatuserid> Find relevant tomcat process id e.g., $ ps -ef grep tcat3 2. $ kill <process id> Stop tomcat 3. $ cd ~/base-cms/webapps WebDAV $ rm rf rest $ rm rest.war $ cp ~/source/cms-cda/dist/rest.war. Do not use kill -9 You can also try: ~tcat3/basecms3/bin/shutdown.s h (however, you should verify that the process actually died) Remove directories generated by war files and copy latest war files from the build 1. $ ps ef grep <tcatuserid> Find relevant tomcat process id e.g., $ ps -ef grep tcat3 2. $ kill <process id> Stop tomcat 3. $ cd ~/base-cms/webapps $ rm rf webdav $ rm webdav.war $ cp ~/source/cms-webdav/dist/webdav.war. Do not use kill -9 You can also try: ~tcat3/basecms3/bin/shutdown.s h (however, you should verify that the process actually died) Remove directories generated by war files and copy latest war files from the build IT Application Support Page 30 02/19/09

34 Preview 1. $ ps ef grep <tcatuserid> Find relevant tomcat process id e.g., $ ps -ef grep tcat3 2. $ kill <process id> Stop tomcat 3. $ cd ~/base-cms/webapps XRE $ rm rf rpreview $ rm preview.war $ cp ~/source/cmspreview/dist/preview.war. Do not use kill -9 You can also try: ~tcat3/basecms3/bin/shutdown.sh (however, you should verify that the process actually died) Remove directories generated by war files and copy latest war files from the build 1. $ ps ef grep <tcatuserid> Find relevant tomcat process id e.g., $ ps -ef grep tcat3 2. $ kill <process id> Stop tomcat 3. $ cd ~/base-cms/webapps $ rm rf xre $ rm xre.war $ cp ~/source/cms-xre/dist/xre.war. Do not use kill -9 You can also try: ~tcat3/basecms3/bin/shutdown.sh (however, you should verify that the process actually died) Remove directories generated by war files and copy latest war files from the build IT Application Support Page 31 02/19/09

35 Start Tomcat 1. cd ~tcat3/base-cms/bin/;./startup.sh Start tomcat 2. Check latest log file in: ~tcat3/base-cms/logs/ Sanity Test 1. Log into CMS: 2. Open existing, preview or create new content. 3. Verify proper functioning of CMA, CMA Front-End and CDA Core. Rollback 1. Deploy previous WAR file. IT Application Support Page 32 02/19/09

36 APPENDIX F: PROD CDA CORE BUILD & DEPLOYMENT RUN PROCEDURES For detailed instructions on the operational tasks involved in PROD builds and deployments, see the CollabNet documentation repository: IT Application Support Page 33 02/19/09

37 APPENDIX G: TEMPLATE & FRONT-END FILE BUILD RUN PROCEDURES Requirements 1. Java 1.5 (java -version) Preparation Ant 1.7 (ant -version) Subversion 1.5 Client (svn --version) Cached credentials for site's Subversion repository (e.g., a previous checkout) 1. Go to C:\CMS2\RS\sites To use packaging and deployment scripts, files for site and environment properties must be pre-filled (assuming these scripts are running in Windows environment) 2. edit <site_id>.properties e.g., edit rs.properties 3. Update value depends on Title: cda.repos= redesign08.collabnet.net/svn/ /projects/rs-cda feds.repos= redesign08.collabnet.net/svn/ redesign08/projects/rs-feds 4. Save file and exit. 5. Go to: C:\CMS2\RS\environments mkdir <site_id> (eg mkdir rs for real simple) 6. Go to: C:\CMS2\RS\environments\<site_id> edit <environment_id>.properties 7. Update value depends on environment: dav.server=<hostname>:<port number> dav.user= dav.password= e.g., edit <qa.properties> Packaging IT Application Support Page 34 02/19/09

38 1../package.sh <site_id>./package.sh <site_id> branch <branch_ name>./package.sh <site_id> tag <tag_name> Daily build from the trunk Daily build from branch Release build from Tag Examples:./package.sh rs./package.sh rs branch rel2.0_rc1./package.sh rs tag rel2.0_rc1 IT Application Support Page 35 02/19/09

39 APPENDIX H: TEMPLATE & FRONT-END FILE DEPLOYMENT RUN PROCEDURES Deployment 1../deploy <site_id><environment_id><zip_file> Example:./deploy rs qa zip Note: Deployment process employs WebDAV to "upload" CDA Core Templates and XSLT to the JCR. Deployment of Front-End File resources is still under construction. IT Application Support Page 36 02/19/09

40 APPENDIX I: PROD TEMPLATE & FRONT-END FILE BUILD & DEPLOYMENT RUN PROCEDURES For detailed instructions on the operational tasks involved in PROD builds / deployments, see the CollabNet documentation repository: IT Application Support Page 37 02/19/09

41 APPENDIX J: BASE & TITLE-SPECIFIC CONTENT TYPE CHANGE BUILD & DEPLOYMENT PROCEDURES Title-Specific Content Type Changes Build Performed manually by Title Tech Lead Deployment Manual import Synchronization script required for complex changes. Base Content Type Changes Build Performed manually by Architecture Team Deployment Manual import Synchronization script required for complex changes Coordination with affected Titles required IT Application Support Page 38 02/19/09