TheTricky Bits of Deployment Automation

Post on 11-May-2015

693 views 2 download

Tags:

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 updates

Transcript of TheTricky Bits of Deployment Automation

The Tricky Bits of Deployment Automation:Mainframe Code, WAS Configuration, Databases

Eric MinickIBM DevOps EvangelistIBM Software, Rationaleminick@us.ibm.com@ericminick

Robert ReevesChief Technology OfficerDatical, Inc.r2@datical.com@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 Minickeminick@us.ibm.com

@ericminick

Questionsucinfo@us.ibm.com

DaticalDB4UDeploydatical.com/ibm

Bring Agile Development to the Database

datical.com/agile

info@datical.com(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