Deployment Automation:Serena Release Automation

Kev Holmes

Solutions Architect

2

Who is Kev Holmes?

• Englishman, living in England

• BSc. Computer Science, University of Warwick, 1982

• 30+ years in professional software companies

• Focus on software development tools and processes

• When not working is usually found playing the decadent sport known as “Golf”

4

Deployment Automation – the players

The Developer

The Tester Operations

The Business InternalCompliance

ExternalCompliance

5

Releasing software used to be easy...

Development Testing Operations

6

But things became complex...

• Larger teams

• Client/Server

• Virtualisation

• Offshore development

• Automated testing suites

• The Cloud

• Change requests

• Workflow Approvals

• The “Business” wanting greater visibility of the process

• ...

7

Increased Complexity – An Example

8

In Reality...

!

9

To counter the complexity, new initiatives...

• Continuous Integration• TeamCity, Hudson/Jenkins

• Continuous Testing

• Dynamic Provisioning (of virtual environments)

• DevOps...

• Continuous Deployment

10

“Joined-up Thinking”

If we can do all of these things individually, why don’t we put them all

together?

11

Questions

When doing a release, there are some important questions that need to be asked...

What? Where?

How? Why?

Who and When?

12

Serena Provides Both Release Control and Automation

Release Automation SystemRelease Control System

Why?When?Who?

What?Where?How?Who?When?

13

A Good Release Process Needs a Release Control System

Visibility & TrackingCentral release calendar, process metrics, dashboards

ComplianceWork management with routing rules, approvals, logs

Collaboration and CoordinationShared and centralized work items

FlexibilityCustomize workflow for individual enterprise needs

Multiplatform SupportDistributed and Mainframe

Investment ProtectionIntegration with existing toolsRelease Control System

14

Quality, predictability Repeatable, consistent procedures

ThroughputMaximize content through a release window

Productivity and VelocityThe system is always ready to work

FlexibilityPer environment configuration

SimplicityIntuitive and visual programming approach

TraceabilityArtifact repository for single source of truth on release assets

Release Automation is the Foundation for an Efficient and High Quality Path-to-Production

Release Automation System

15

Why use Deployment Automation?

• Effectiveness• By automating the process, vital steps don’t get missed

• Repeatable processes• We have done it once, now, let’s do it again

• Visibility• When will that deployment be completed? Which change

requests are in a release and which aren’t?

• Auditable processes• Who did what, when and where?

16

What should a Deployment Automation system do?

• Support intuitive modelling of the structures that need deploying

• Be able to model any kind of deployment process

• Support multiple processes per deployable entity

• Allow easy definition of the target environments

• Act as a “System of Record”

• Easily interact with external systems and tools

• Support reporting for all levels of users

17

Intuitive Modelling of Deployment Structures

• Almost every system is represented as some form of decomposed hierarchy

• Therefore, in Serena Release Automation, the lowest level of deployable entity is a Component

• Each Component may have different deployment processes associated with it

• Applications are then made up of collections of Components

• Deploying an Application invokes the appropriate processes on the Components within it

Example: A Client-Server application may have an application server component, a database component and a client component

18

Model Any Kind of Deployment Process

• Most current deployment operations are defined in a “Run-Book” – a list of instructions that must be followed in sequence – typically manually

• Serena Release Automation allows these instructions to be defined as “steps” within a deployment process at both the Component and Application level

• Any instruction can be defined in this way

19

Support Multiple Processes per Deployable Entity

• Applications and Components can be deployed using different processes according to circumstances

Example:- A ‘main’ release may require more sign-off steps than an “Emergency bugfix” release where speed is the priority

• Create a library of deployment processes covering all possible deployment scenarios, including rollback

20

Allow Easy Definition of Target Environments

At some point content needs to be deployed to a target “Environment”. These Environments may be:-

• Machines serving a particular purpose (i.e. application server, database server, etc.)

• A minimal configuration representing a test environment

• Located anywhere in the world

• Real or virtual (i.e. a VM or in the Cloud)

By supporting the abstraction of such environments, Serena Release Automation allows the user to select where their deployment is intended by function rather than having to remember a list of machine names

21

Act as a “System of Record”

• Serena Release Automation records every operation it makes

• It takes an archival copy of all content that it deploys

• Captures all information that needs to by handed from one team to the next in the process

• Aggregates all results and logs from the machines within the target environments

• Users now only have to look in one place for the details of a release

22

Easy Interaction With External Systems and Tools

• Serena Release Automation has been designed to work in conjunction with other tools and technologies

• A library of plugins is available offering parameterised interaction with commonly used tools

• This even applies to home-grown or emerging technologies

23

Support Reporting For All Levels of Users

• To understand what is occurring with their deployment processes, users have access to the data captured by Serena Release Automation

• This can be presented in a wide variety of pre-defined reports, or configured as the user requires

• If desired, this information may be packaged for transfer on to other systems

Example:- The successful completion of a deployment to a test environment and the results of the automated test that SRA invoked there could be passed to an Change Request Management system for recording against an Engineering Change Order (i.e. a bugfix)

24

How SRA Helps in Our Earlier Example

!

25

Top-Level View

(Assuming a Virtualised or Cloud environment)

For each deployment, Serena Release Automation can:-

• Create an image of each machine from dedicated templates

• Deploy each Component using the required process

• Run the required operations/tests on the deployed machines

• “Tear down” the newly created machine instances on completion

Without requiring a member of the Operations team to do anything!

26

In summary

• Deploying software has become very complex

• Typically, deployments require more than one user to action

• The number of deployment cycles increases faster than the complexity

• Deployment operations utilise multiple processes

• Automation provides a means of managing the processes

• Serena Release Automation provides a framework capable of supporting deployments of any complexity and any scale

27