NES Applications

What is DevOps?
1 August 2014

CSC
CSC Proprietary
Proprietary and
and Confidential
Confidential 1
 What is DevOps?
▪ DevOps is an enterprise capability for Continuous Software Delivery
▪ DevOps is an integrated coupling of Process, Infrastructure, and Product
▪ DevOps is the productive intersection of Cross Team Cooperation

DEVOPS emphasizes:
• Flexibility
• Agility
• Automation
• Collaboration
• Communication
• Cross-team cooperation
• Ownership

The walls separating development, QA, and production are barriers to agility. DevOps
breaks down these walls. DevOps is a new culture and process where Development,
QA, and Operations work together to expedite development and problem resolution.
CSC Proprietary and Confidential 2
Why DevOps?
Drivers
• Reduced deployment and operational
outage times
• Reduction of human-in-the-loop errors
• Pressure to deliver higher quality
applications faster
CSC Proprietary and Confidential
Benefits
• Expedited deployment process using
increased automation (i.e. deployment,
configuration, testing (less time, less
manual effort))
• Increased collaboration among
departments (i.e. Dev, QA, Operations)
• Improvement in quality of applications
deployed, time-to-market speed
• Reduction in spend on deployment
operations caused by human-in-the-
loop
• Reduced IT cycle time
3
 Trust

Why DevOps is Critical? Collaboration Improve

Communication

 Many initiatives, many teams, common challenges

– Governance, environment availability and utilization, COTS dependencies,
Shared Services dependencies, release scheduling, common tools and views,
system privileges, release automation, etc.
Common COTS
Environment Taxonomy Layout (recommendation) Example SIP Catalog
HCQIS Environments - Today Legacy Server configuration settings
instances to be
 Discussion OS and OS OS , OS OS , OS
The ‘2’ instance stack (IT2- The ‘1’ instance stack (IT1-QA1-VV1) is Production
defined
Patches, WLS, Common COTS
QA2-VV2) is the host for the being upgraded in July 2014 from WL Patches Patches,
HQR 6.0 and QIO 4.0 10.3.4 to 10.3.6 WLS 10.3.6 BPEL
Deployments under CP
2.2/FiIM1.5/MFT 1.0
OS configuration
Environment ID TEA_TEST2

Gold/ITF 2 Curr Gold/ITF 1 Prod Fix/ITF Gold

OS , OS OS , OS OS and OS patches
Implementation L1 L2 L3 Patches, Patches, ETC…
ES Appl. Objects ES Appl. Objects ES Appl. Objects Domain ID WCDOMAIN DADOMAIN …
Cognos
Legacy Servers
Oracle DB Virtual Machine
Domain Class ID WebCenter BPM UCM SRV

Gold 2 Curr Gold 1 Prod Fix Gold

Test L1 L2 L3 Domain Object ID Admin Collab Spaces Utilities WSM SOA BAM Content Admin RTDA
ES Appl. Objects ES Appl. Objects ES Appl. Objects Install/Configure
Start Object End
Legacy Servers
Cluster or Machine Name Wc_collaboration_cluster

Engineer Gold 2 Curr Gold 1 Prod Fix Gold PQ PQ HQ

& Automate
Gold ES Appl. Objects ES Appl. Objects ES Appl. Objects RS RS R Property=value ClusterNumberMachines=3

Verify Validate
Legacy Servers Dependencies Installed Object
Development

HQR ES QIO PQRS QIP

HQRDev 3 ES
Dev 3 QIO
Dev 3 PQRS
Dev 3 QIPDev 3 COTS UPGRADES
HQR
Dev 2 Dev 2
ES
Dev 2
QIO
Dev 2
PQRS
Dev 2
QIP
The Environment taxonomyDPLANis not meantAutomation Environment
to include “application Considerations
Dev 1 Dev 1 Dev 1 Dev 1 Dev 1
VIRTUAL MACHINE (VM)
specific” property values. Application/ADO/LOB Administrative
specific property Privilege Control
Note:
QIP Instances not yet
values may be maintained directly
Environmentby the ADO for use with developed
SIP Installation
Responsibility
DPLAN
Installation
Security
Account
Security
Account

7/10/2014 White background indicates future instance to be established

defined installation scripts as necessary (e.g., queue names, etc.) Responsibility Controls (root
or sudo)
Controls (non-
root)

Lower Environments
HQR 9.0 HQR 11.0 Laptop GDIT Developer GDIT Developer
TEA 3.0
(CP 2.3, PRIS 2.0, FIM 1.5.1, MFT 3.0)
ES LOB GDIT ES +DSG GDIT1 ES Team Developed Software
PQRS Dec 2014
GPRO, Submissions
PQRS March 2015
(Measures Engine) HQR 10.0
DECC DEV ADO GDIT LOB +DSG GDIT1 ADO Team
Configuration
Non-DECC DEV ADO GDIT ADO GDIT1 ADO Team
Engineering & Automation GOLD GDIT DECC DSG with GDIT1 ES/ADO Team Developed Software (DB
(DPLAN Automation Dev) LOB or ADO
support Schemas, Data, Code Objects) Data,
DEV GOLD (after DPLAN review) GDIT DECC DSG GDIT1 DECC DSG
1 Dec 1 Jan 1 Feb 1 Mar 1 Apr 1 May 1 Jun 1 Jul 1 Aug 1 Sep 1 Oct 1 Nov 1 Dec
Upper Environments
TEST (QA) GDIT GDIT GDIT GDIT Application Unique COTS configuration
IMPL (V&V, Security, Perf Test) GDIT GDIT GDIT GDIT
HQR 7.0 PQRS June 2015 PQRS Dec 2015
(Feedback Dashboard) GRO, Submissions PRD (Production) GDIT GDIT GDIT GDIT
HQR 8.0 PROD PQRS September 2015

TEA 4.0
(TBD) Individual access to environments beyond guidance above is on exception basis only Application Unique COTS
QIO 4.2
(CP 3.0, QARM 1.0, PRIS 2.0, QARM DECC DSG = DECC Development Support Group
Q1 Q2 1.0, DAS 1.0, MFT 4.0) Q3 Q4 GDIT1 = GDIT retains control of root and will temporarily enable DECC DSG or ADO Admin privilege on a request/exception basis

Components of DevOps are already being performed (release planning, environment

planning, deployment scripting, COTS upgrades, etc.). Streamlining will improve
agility, flexibility, and automation.
CSC Proprietary and Confidential 4
As a Developer or Engineer why do I care about DevOps?

 Improved Quality of Life

– Expedited deployment process (less time, less manual effort)
– Fewer calls in the middle of the night, on weekends

 Pride of Ownership
– Developers own the delivery of the code from inception through
implementation to the end-user

 Relevance
– Troubleshooting information is shared across silos
– Developers view the direct use and benefit of their software
– Developers are directly involved in the feedback loop

CSC Proprietary and Confidential 5

Where to Begin…Define Governance Model
DEVOPS Governance Board Review and Coordination

 “JUST ENOUGH” Governance is required for DevOps:

– Provisioning: Review, control, and promotion of “common” configuration to Virtual Machine
controlled images for consistency and reuse
• Prevents duplication of configuration effort by development organizations
• Alleviates development organizations from “stepping on” each other for core COTS configuration settings
– Coordination of Resource Utilization (environments)
– Common Tools
– Standard Taxonomy
– Application Stack Control
• Environment and VM access rights
• Environment and VM resource limits
• COTS admin access rights
• Software Promotion/Deployment Control Points
– Peer Review, CM control, and promotion of deployment script methodology and content for
consistency
• Deployment automation scripts ARE code; are checked in to CM before build request
– Configuration Control of all configurable parameters (common and unique)
– Build coordination (approval)
– Deployment coordination (approval)
– Recovery Methodology

CSC Proprietary and Confidential 6

DevOps Steps to Maturity

1. Define a Charter
2. Document your Governance Model
3. Ensure Active Stakeholder Participation
4. Establish Build Automation for expedited turnaround
5. Develop Automated Testing for Continuous Integration Testing
6. Establish Deployment Automation for Continuous Delivery and to reduce
planned deployment outage time
7. Streamline the Continuous Integration and Continuous Delivery process to
implement automaton to the fullest extent possible
8. Continue to mature these items if they don’t already exist:
• Create/Maintain a catalog of pre-built platform images for streamlined re-use and recovery
capability
• Standardize tools to ensure a single authoritative source of knowledge
• Continue to mature your change management process
• Continue to eliminate barriers for productivity and performance
• Implement application monitoring and automated dashboard reporting to increase visibility

CSC Proprietary and Confidential 7