Configuration Management Plan · projects are managed using Collabnet, a . distributed knowledge...

CMS (Publishing System)

Change and Release Management Plan

February 19, 2009 Version 1.1

Page ii 02/19/09

Table of Contents

1. OBJECTIVES __________________________________________________________________ 1

2. SCOPE _______________________________________________________________________ 1

2.1 Project Tracking & Version Control Tools ________________________________________ 1

3. GLOSSARY ___________________________________________________________________ 2

4. CURRENT CHANGE CONTROL PROCESS _________________________________________ 5

4.1 Current Development Responsibility Matrix ______________________________________ 5

4.2 Current Build & Deployment Responsibility Matrix ________________________________ 5

4.3 Current CMA, CDA Core & CMA Front-End (FLEX) Change Control __________________ 6

4.4 Current Template & Front-End File Change Control ________________________________ 8

4.5 Current Base & Title-Specific Content Type Change Control _______________________ 10

5. PROPOSED CHANGE CONTROL PROCESS _______________________________________ 11

5.1 Improving CMS Change Management Process ___________________________________ 12 5.1.1 Implement Formal Change Control Board ___________________________________ 12 5.1.2 Define Roles & Responsibilities ___________________________________________ 12 5.1.3 Create New Tools _______________________________________________________ 12 5.1.4 Improve Communication _________________________________________________ 12 5.1.5 Improve Build & Deployment Procedures ___________________________________ 13

5.2 Proposed Development Responsibility Matrix ___________________________________ 13

5.3 Proposed Build & Deployment Responsibility Matrix _____________________________ 14

5.4 Proposed CMA Change Control _______________________________________________ 15

5.5 Proposed CMA Front-End (FLEX) Change Control ________________________________ 16

5.6 Proposed CDA Core Change Control ___________________________________________ 17

5.7 Proposed Template & Front-End File Change Control _____________________________ 18

5.8 Proposed Base & Title-Specific Content Type Change Control _____________________ 19

5.9 How Do We Get Here? _______________________________________________________ 20

6. Tools _______________________________________________________________________ 21

6.1 Currently In Use ____________________________________________________________ 21

6.2 Work in Progress ___________________________________________________________ 22

6.3 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 iii 02/19/09

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

IT Application Support Page 1 02/19/09

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


3. GLOSSARY

Terms Definition

Admin Tool 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 customer-facing environments

• Tools: reporting, file management, and cleaning or publishing switches for publications

Build In the software industry, this term refers to the compilation process during which source code files are converted into executable code.

Build Repository 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.

CCB Change Control Board

CDA Content Delivery Application: CMS component that allows rendering and pre-caching of all published content; resides on the CMA and the Extreme Rendering Engine.

Checksum 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.

CM Configuration Management or Change Management

CMA 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.

CMA Front-End CMS editorial interface; the FLEX component of UI in the system.

CollabNet® 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.

CSS 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.

FLEX 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.

JS JavaScript: a scripting language widely used for client-side web development.

MXML The XML-based user interface markup language used by the FLEX-based CMA Front-End for client-server communication.

http://en.wikipedia.org/wiki/Data

http://en.wikipedia.org/wiki/Digital

http://en.wikipedia.org/wiki/Error_detection

http://en.wikipedia.org/wiki/Computer_storage

http://en.wikipedia.org/wiki/Scripting_language

http://en.wikipedia.org/wiki/Client-side

http://en.wikipedia.org/wiki/XML

http://en.wikipedia.org/wiki/User_interface_markup_language


Terms Definition

QA Quality Assurance

Release The distribution (either public or private) of an initial or upgraded version of a software product.

Release Manager 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:

Normal:

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.

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 Request Management System

Rollback A procedure that allows committed changes and updates to be returned to the previous state.

Saxon 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.

SWF 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.

Subversion® An open source, version control and SCM system, which serves as repository for CMS-related source code.

CMS 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.

CMS UI The CMS User Interface: an intuitive user interface built to be “editor-friendly,” easy to learn and use.

Tomcat Provides a “pure Java” HTTP web server environment to run Java code; developed by the Apache Software Foundation (ASF).

WAR File (WAR is short for Web ARchive.) A JAR file format used to distribute a collection of files that together constitute a Web application.

WebDAV 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 Extreme Rendering Engine: CMS component that renders content published within the CMS CMA.

XSLT XSL Transformations: part of the Extensible Stylesheet Language (XSL) family; CMS


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.


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

Category Responsibilities CMA Architecture Team is responsible for JAVA Code.

CMA Front-End (FLEX)

FLEX Team is responsible for MXML and SWF.

CDA Core Architecture Team is responsible for JAVA Code and XSLT Core.

Base Content Type Title Dev Team requests Base Content Type changes; Architecture Team approves and then makes these changes.

Title-Specific Content Type

Architecture Team approves Title-Specific Content Type change requests; Title Dev Team then makes these changes.

Templates Title Development Team is responsible for XSLT and XML.

Front-End Files 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


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


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: https://iao-docs.collabnet.net/source/browse/*checkout*/iao-docs/trunk/CMS%20Release%20Docs/CMS_CMA-CDA-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

https://iao-docs.collabnet.net/source/browse/*checkout*/iao-docs/trunk/CMS%20Release%20Docs/CMS_CMA-CDA-FLEX_CM_Today_Workflow_files/CMS_CMA-CDA-FLEX_CM_Today_Workflow_frames.htm?revision=66

https://iao-docs.collabnet.net/source/browse/*checkout*/iao-docs/trunk/CMS%20Release%20Docs/CMS_CMA-CDA-FLEX_CM_Today_Workflow_files/CMS_CMA-CDA-FLEX_CM_Today_Workflow_frames.htm?revision=66


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.


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: https://iao-docs.collabnet.net/source/browse/*checkout*/iao-docs/trunk/CMS%20Release%20Docs/CMS_Current/CMS_TemplateFrontEndFile_CM_Today_files/CMS_TemplateFrontEndFile_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.

https://iao-docs.collabnet.timeinc.net/source/browse/*checkout*/iao-docs/trunk/TIPS%20Release%20Docs/TIPS_Current/TIPS_TemplateFrontEndFile_CM_Today_files/TIPS_TemplateFrontEndFile_CM_Today_frames.htm?revision=48




• 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.


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.


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.


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.

5.1.1 Implement Formal Change Control Board

• An internal change control board (CCB) will be formed.

o Will chair meetings for review and approval of CMA, CMA Front-End (FLEX) and CDA Core changes.

o 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.

5.1.2 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.

5.1.3 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.

Title-specific build scripts will be maintained under each Title’s Subversion project structure.

5.1.4 Improve Communication

• 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.


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 Responsibilities CMA Architecture Team to be responsible for JAVA Code.

CMA Front-End (FLEX) FLEX Team to be responsible for MXML and SWF.

CDA Core Architecture Team to be responsible for JAVA Code and XSLT Core.

Base Content Type Title Dev Team to request Base Content Type changes; Architecture Team to approve and then make these changes.

Title-Specific Content Type Architecture Team to approve Title-Specific Content Type change requests; Title Dev Team to make these changes.

Templates Title Development Team to be responsible for XSLT and XML.

Front-End Files Front-End Development Team to be responsible for CSS and JS.


5.3 Proposed Build & Deployment Responsibility Matrix

Type of Build Request

QA Build QA Deployment & Script Execution

PROD Deployment & Script Execution

CMA Architecture Lead

Web Ops Engineer Web Ops Engineer


FLEX Lead Web Ops Engineer Web Ops Engineer

CDA Core Architecture Lead

Web Ops Engineer Web Ops Engineer

Base Content Type

Architecture Lead

Application Support Application Support

Title-Specific Content Type

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 Responsibilities

CCB Will analyze and approve CMS changes.

Release Manager Will coordinate and schedule builds.


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.]


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.]


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.]


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.]


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.]


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).


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 https://CMS.collabnet.net/wiki/DeleteCitems_Tool

• Content Type Synchronization Tool https://CMS.collabnet.net/wiki/Synchronizer_Tool

• Content Type Move Channel Tool https://CMS.collabnet.net/wiki/MoveChannel_Tool

• Content Item Mass Preview Tool https://CMS.collabnet.net/wiki/MassPreview_Tool

• Template & Front-End File Mass Rendering Tool https://CMS.collabnet.net/wiki/MassRender

• Template & Front-End File Mass Publish Tool https://CMS.collabnet.net/wiki/MassPublish_Tool

• Data Import Tool https://CMS.collabnet.net/wiki/CMS_Data_Import

• Data Export (Data Migration) Tool https://CMS.collabnet.net/wiki/Content_Tool_XML_Data_Export_Project

• CMS Title-Specific Admin Tool https://CMS.collabnet.net/wiki/CMS_environments

• Redirect Generator Tool https://CMS.collabnet.net/wiki/Redirect_Generator

• Bulk User Creation Tool https://CMS.collabnet.net/wiki/Bulk_Create_Users

https://cms.collabnet.net/wiki/Synchronizer_Tool

https://cms.collabnet.net/wiki/MoveChannel_Tool

https://cms.collabnet.net/wiki/MassPreview_Tool

https://cms.collabnet.net/wiki/MassRender

https://cms.collabnet.net/wiki/MassPublish_Tool

https://cms.collabnet.net/wiki/CMS_Data_Import

https://cms.collabnet.net/wiki/Content_Tool_XML_Data_Export_Project


6.2 Work in Progress

Tools Team Responsible Admin Tool (Web Interface) Architecture/Application Support

Build & Deployment Tool (Web Interface) Architecture

Bulk Delete Tool (Saxon) Architecture

Bulk Expire Tool (Saxon) Architecture

Bulk User Load Tool (Saxon) Architecture

Channel Mover Tool (Web Service) Architecture

Content Explorer Tool (Web Interface) Architecture

Content Item Synchronization Tool (Web Service) Architecture

Continuous Integration Tool (Web Interface) Architecture

Import Rest Layer Tool (Web Interface) Architecture

Mass Preview Tool (Web Service) Architecture

Mass Publish Tool (Web Service) Architecture

Mass Render Tool (Web Service) Architecture

Rest Layer Tool (Web Interface) 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)


APPENDIX A: QA CMA & CMA FRONT-END (FLEX) BUILD RUN PROCEDURES

Back-End CMA

Step Action Description

1. $ ssh <tcatuserid>@<hostname> e.g., ssh [email protected]

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



2. $ cd ~/sources/CMS2.0_GUI Go to sources directory



5. $ ls -ltr ~/sources/CMS2.0_GUI/deploy Check time stamps of files in folder to determine if successful

Front-End Admin Tool UI



2. $ cd ~/sources/CMA_Admin Go to sources directory



5. $ ls -ltr ~/sources/CMA_Admin/deploy Check time stamps of files in folder to determine if successful

mailto:[email protected]




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

• Do not use kill -9

• You can also try: ~tcat3/baseCMS3/bin/shutdown.sh (however, you should verify that the process actually died)

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/CMS-cma-admin-<current_date>.war

Not mandatory for DEV/QA

4. • $ cd ~/base-CMS/webapps

• $ rm –rf CMS_cma

• $ rm CMS_cma.war

• $ cp ~/source/CMS-cma/dist/CMS_cma.war .

Remove directories generated by war files and copy the latest war files from the build

CMS UI [FLEX changes]

Step Action Description 1. $ ps –ef | grep <tcatuserid> • Find relevant tomcat process id

• e.g., $ ps -ef | grep tcat3 )




3. • $ cd ~/base-CMS/webapps/ROOT/CMS/CMS2

Clean up existing files and copy the latest files from the build



• $ rm –rf *

• $ cp -r ~/source/CMS2.0_GUI/deploy/ .

4. $ vi assets/xml/CMSInit Edit CMSInit file

5. • <HTTPServices>

• <HTTPService id="loginHTTPService" url="https://<hostname>/CMS_cma/security/login.xml" showBusyCursor="true" method="POST" /> <HTTPService id="logoutHTTPService" url="https://<hostname>/CMS_cma/security/logout.xml" showBusyCursor="true" method="POST" />

• </HTTPServices>

• Comment out “HTTPServices” xml containing “localhost”

• Uncomment out “HTTPServices” xml containing “qa-CMS2” and update hostname in the URL value accordingly

6. Save the file :wq

Admin Tool UI




2. $ kill <process id>

• Stop tomcat



3. • $ cd ~/base-CMS/webapps/ROOT/CMS/admin

• $ rm –rf *

• $ cp -r ~/source/CMA_Admin/deploy/ .

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 https://qa-CMS2.net


Start Tomcat


1. cd ~tcat3/base-CMS/bin/; ./startup.sh Start tomcat

2. • Check latest log file in ~/base-CMS/logs/

• Determine if you can log into CMS UI: https://qa-CMS2.net/CMS/CMS2/CMS2.html

Sanity Test

Step Action Description 1. Log into CMS:

https://CMS2.net/CMS/CMS2/CMS2.html

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.


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:

• https://ie-open.collabnet.net/wiki/OperationalTasks

https://ie-open.collabnet.net/wiki/OperationalTasks


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



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



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

Step Action Description 1. $ ssh <tcatuserid>@<hostname> e.g., ssh [email protected]

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



2. $ cd ~/sources/xre Go to sources directory 3. $ svn up Update source from Subversion






Step Action Description 4. $ ant Run ant to start build process

5. $ cd ~/build/xre/dist/ Determine if xre.war file exists by checking specified directory


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








• $ rm –rf rest

• $ rm rest.war

• $ cp ~/source/CMS-cda/dist/rest.war .

Remove directories generated by war files and copy latest war files from the build

WebDAV







• $ rm –rf webdav

• $ rm webdav.war

• $ cp ~/source/CMS-webdav/dist/webdav.war .



Preview








• $ rm –rf rpreview

• $ rm preview.war

• $ cp ~/source/CMS-preview/dist/preview.war .


XRE







• $ rm –rf xre

• $ rm xre.war

• $ cp ~/source/CMS-xre/dist/xre.war .



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: https://CMS2.net/CMS/CMS2/CMS2.html

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.


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:




APPENDIX G: TEMPLATE & FRONT-END FILE BUILD RUN PROCEDURES

Requirements


1. • Java 1.5 (java -version)

• Ant 1.7 (ant -version)

• Subversion 1.5 Client (svn --version)

• Cached credentials for site's Subversion repository (e.g., a previous checkout)

Preparation


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=https:// redesign08.collabnet.net/svn/ /projects/rs-cda

• feds.repos=https:// 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

e.g., edit <qa.properties>

7. Update value depends on environment:

• dav.server=<hostname>:<port number>

• dav.user=

• dav.password=

Packaging


Step Action Description 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


APPENDIX H: TEMPLATE & FRONT-END FILE DEPLOYMENT RUN PROCEDURES

Deployment


1. ./deploy <site_id><environment_id><zip_file> Example:

./deploy rs qa 200810250930.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.


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:




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

Step Action Description Build Performed manually by Architecture Team

Deployment • Manual import

• Synchronization script required for complex changes

• Coordination with affected Titles required

Date post:	16-Nov-2019
Category:	Documents
Upload:	others
View:	9 times
Download:	1 times

Configuration Management Plan · projects are managed using Collabnet, a . distributed knowledge...

Documents