thetricky bits of deployment automation
DESCRIPTION
Deployment automation efforts tend to start with easier scenarios like moving builds of web applications to servers and getting them installed. However, some parts of our applications aren’t simple builds. They may be updated incrementally; changes may be non-repeatable; or they may be dependent on knowledge contained within some other tool or framework. When we fail to automate changes to these “tricky” parts of our application, errors and delays materialize. Eric Minick from IBM, and Robert Reeves, database guru from Datical, discuss what makes certain things hard to deploy, and practical techniques and tools for deploying them. Topics covered include: * What causes certain deployments to be trickier to automate than others * Successful patterns for overcoming those challenges * Application of those techniques to mainframe changes, WebSphere configuration and database schema updatesTRANSCRIPT
The Tricky Bits of Deployment Automation:Mainframe Code, WAS Configuration, Databases
Eric MinickIBM DevOps EvangelistIBM Software, [email protected]@ericminick
Robert ReevesChief Technology OfficerDatical, [email protected]@robertreeves
Agenda
What makes something hard to deploy?
Why do it anyway?
Three examples:
–Database schema updates
–Mainframe code changes
–WebSphere Application Server configuration changes
Q&A
What makes something hard to deploy?
Where “Something” = Component of an app
Easy things to deploy fit the classic pipeline
Code turned into apackage by a build
A version of the thingcan be stored on the
file system
The stuff in theenvironment is
what is in the repo
Rolling back is justredeploying the old
version
Hard things break the build promotion model
Not source controlled
Changes are incremental
Not owned by development
Deploy process is inconsistent
Agenda
What makes something hard to deploy?
Why do it anyway?
Three examples:
–Database schema updates
–WebSphere Application Server configuration changes
–Mainframe code changes
Q&A
Why Automate the Hard Stuff?
Because that stuff is partof our application.
Without Automation:• We make mistakes• We forget things• We schedule based on
engineer availability
Agenda
What makes something hard to deploy?
Why do it anyway?
Three examples:
–Database schema updates
–WebSphere Application Server configuration changes
–Mainframe code changes
Q&A
Database Change Management Challenges
Test
Development
Build
Code
Database Change Management Challenges
Test
Release
Test
Development
Build
Code
Database Change Management Challenges
ProductionTest
Release
Test
Development
Build
Code
Database Change Management Challenges
Production
SQL Script 1
SQL Script 3
SQL Script 2
Test
Release
Test
Development
Build
Code
Database Change Management Challenges
Production
SQL Script 1
SQL Script 3
SQL Script 2
Test
Release
Test
Development
Build
Code
Database Change Management Challenges
Production
SQL Script 1
SQL Script 3
SQL Script 2
Test
Release
Test
Development
Build
Code
Database Change Management Challenges
Production
SQL Script 1
SQL Script 3
SQL Script 2
Test
Release
Test
Development
Build
Code
Database Change Management Challenges
Production
SQL Script 1
SQL Script 3
SQL Script 2
Test
Release
Test
Development
Build
Code
Database Change Management Challenges
ProductionManual Change Manual Change
SQL Script 1
SQL Script 3
SQL Script 2
Test
Release
Test
Development
Build
Code
Database Change Management w/Datical DB
Test
Development
Build
Test Production
ReleaseCodeCode DaticalDB
Database Change Management w/Datical DB
Test
Development
Build
Test Production
ReleaseCodeCode DaticalDB
ModelEasily create and model database changes across your software release stages.
Database Change Management w/Datical DB
Test
Development
Build
Test Production
ReleaseCodeCode DaticalDB
ModelEasily create and model database changes across your software release stages.
ForecastProactively scrutinize the impact of database changes in production – or any other environment – before you deploy.
Database Change Management w/Datical DB
Test
Development
Build
Test Production
ReleaseCodeCode DaticalDB
ModelEasily create and model database changes across your software release stages.
ForecastProactively scrutinize the impact of database changes in production – or any other environment – before you deploy.
DeployDeploys database schema changes to multiple databases and mixed environments simultaneously.
Database Change Management w/Datical DB
Test
Development
Build
Test Production
ReleaseCodeCode DaticalDB
ModelEasily create and model database changes across your software release stages.
ForecastProactively scrutinize the impact of database changes in production – or any other environment – before you deploy.
DeployDeploys database schema changes to multiple databases and mixed environments simultaneously.
ManageConfidently know the current state of the database and how it got there across the application release lifecycle.
Datical Product Overview
Deploy Plan
DEV
QA
PROD
Datical Product Overview
Deploy Plan
DEV
QA
PROD
Datical DB Engine
Datical Product Overview
Deploy Plan
DEV
QA
PROD
ChangeSet 1
ChangeSet 2
ChangeSet 3
ChangeLog
Datical DB Engine
Datical Product Overview
Baseline
Captures the current state of the database
Compare
Provides schema differences between environments
Forecast
Impacts analysis of proposed changes
Deploy
Executes changes to the database
Rollback
Undo select database changes
Audit
Provides visibility into database changes
Deploy Plan
DEV
QA
PROD
ChangeSet 1
ChangeSet 2
ChangeSet 3
ChangeLog
Datical DB Engine
Datical Product Overview
Baseline
Captures the current state of the database
Compare
Provides schema differences between environments
Forecast
Impacts analysis of proposed changes
Deploy
Executes changes to the database
Rollback
Undo select database changes
Audit
Provides visibility into database changes
C:\datialdb.exe
user@host:~$./daticaldb
Datical DB UI Datical DB CLI Integrations
Deploy Plan
DEV
QA
PROD
ChangeSet 1
ChangeSet 2
ChangeSet 3
ChangeLog
Datical DB Engine
Datical Product Overview
Baseline
Captures the current state of the database
Compare
Provides schema differences between environments
Forecast
Impacts analysis of proposed changes
Deploy
Executes changes to the database
Rollback
Undo select database changes
Audit
Provides visibility into database changes
C:\datialdb.exe
user@host:~$./daticaldb
Datical DB UI Datical DB CLI Integrations
Deploy Plan
DEV
QA
PROD
ChangeSet 1
ChangeSet 2
ChangeSet 3
ChangeLog
Datical DB Engine
Agenda
What makes something hard to deploy?
Why do it anyway?
Three examples:
–Database schema updates
–WebSphere Application Server configuration changes
–Mainframe code changes
Q&A
WebSphere Config – What are we deploying?
Let’s see… The app needs:• More memory• Longer timeout setting on the JDBC connector• Subscription to a new message queue
WebSphere Config – Why it’s hard
Not source controlled
Changes are incremental
Not owned by development
Deploy process is inconsistent
Strategy: Infrastructure as Code
Represent Configuration as Files
–Have a “build” than can be versioned
–Can compare versions to see what changed
Requirements for Automation
–Tokenize / Replace per environment settings
–Extract configuration from a known good target
–Apply to other servers
Reliable Middleware Configuration Management
Artifact Library
Application
EAR
WAR
DB
Cluster template
Exemplar WAS Cell
Plugin
Import configuration
WAS Configuration Template Creation
+ Template Assembled
PROD
QA
Dev
Deploy and promote application and configuration across environments
Agenda
What makes something hard to deploy?
Why do it anyway?
Three examples:
–Database schema updates
–WebSphere Application Server configuration changes
–Mainframe code changes
Q&A
Mainframe changes – Why it’s hard
Not source controlled
Changes are incremental
Not owned by development
Deploy process is inconsistent
relies on tribal knowledge
Mainframe changes – Why it’s hard
Worse yet…• We want to keep the files on the box• Test environments are precious
Strategy: Embrace Incremental
Capture builds
Categorize the content
Apply changes incrementally, tracking order.
Build System
Post build script
z/OS DeployToolkit
Create new version
z/OS CodeStation
in USS
Server
Agent
Download artifacts
Review PDS in version and
request deploy process
Pre-processing steps TSO,
REXX, SHELL
Deploy data sets
PDSPDS/E
Update Inventory status
High Level Overview of UrbanCode’s z Deployment Capabilities
z/OS LPAR, Build system z/OS LPAR
Note: LPARs can be the same or different LPARs
Store meta data
Store version artifacts
Fetch artifacts via copy or FTP
Post-processing steps TSO,
REXX, SHELL
deploy
1
2
34
5
6
Summary
Incremental, non-code changes are hard
Two strategies for managing
–Smart incremental updates
–Model full versions, incrementally bring into compliance
Tools exist that help
For more information
IBM UrbanCode Deploy Datical , Inc
IBM developerWorkshttps://developer.ibm.com/urbancode
www.ibm.com
Eric [email protected]
@ericminick
DaticalDB4UDeploydatical.com/ibm
Bring Agile Development to the Database
datical.com/agile
[email protected](949) DATICAL (328-4225)
@daticalfb.com/datical
42
© Copyright IBM Corporation 2013. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in these materials may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo, Rational, the Rational logo, Telelogic, the Telelogic logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others.
www.ibm.com/software
