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”
2
3. Deployment Automation – the players
The Business
Internal
Compliance
External
Compliance
The Developer
The Tester
Operations
4
5. 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
• ...
6
8. To counter the complexity, new initiatives...
• Continuous Integration
• TeamCity, Hudson/Jenkins
• Continuous Testing
• Dynamic Provisioning (of virtual environments)
• DevOps...
• Continuous Deployment
9
9. “Joined-up Thinking”
If we can do all of these
things individually, why don’t
we put them all together?
10
10. Questions
When doing a release, there are some important questions that
need to be asked...
Where?
What?
How?
Why?
Who and When?
11
11. Serena Provides Both Release Control
and Automation
Release Control System
Why?
When?
Who?
Release Automation System
What?
Where?
How?
Who?
When?
12
12. A Good Release Process Needs a Release
Control System
Visibility & Tracking
Central release calendar, process
metrics, dashboards
Compliance
Work management with routing rules,
approvals, logs
Collaboration and Coordination
Shared and centralized work items
Flexibility
Customize workflow for individual
enterprise needs
Multiplatform Support
Distributed and Mainframe
Release Control System
Investment Protection
Integration with existing tools
13
13. Release Automation is the Foundation for an
Efficient and High Quality Path-to-Production
Quality, predictability
Repeatable, consistent procedures
Throughput
Maximize content through a
release window
Productivity and Velocity
The system is always ready to work
Flexibility
Per environment configuration
Simplicity
Intuitive and visual programming
approach
Release Automation System
Traceability
Artifact repository for single source of
truth on release assets
14
14. 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?
15
15. 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
16
16. 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
17
17. 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
18
18. 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
19
19. 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
20
20. 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
21
21. 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
22
22. 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)
23
24. 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!
25
25. 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
26
‘English’ characters chosen to register as “different” with an international audience – I’m looking for something that would be memorable!
Developers used to develop code, pass it to the testing team for testing, who would either reject it back to the developer for alteration and resubmission, or approve it and pass it to Operations for deployment
Just a list of items that have had an impact on complexity – it is, in no way, complete.
In the “olden days” developers were able to test their changes on their own machines (or on test ‘rigs’ that they would manage)Now, the complexity of applications often requires the testing to be carried out on environments made up of multiple machines running multiple technologies... These are typically too complex or time-consuming for the developer to set them up and maintain them, so the Operations team has to do it.Some of the conversations I have had with development teams recently suggest that it might take the Ops team weeks to prepare test environments...
In reality, *every* player needs access to a working environment, either on an individual or shared basis. The overhead on the Operations team is too much to bear! This effort can be massively reduced with modern technology; virtualisation and dynamic provisioning allow the developers and testers to self-service their own environments.The “Good News” about this is that every player is performing a deployment operation to their environment – if a deployment process fails for a developer, they can address the problem before a tester encounters the problem.
Continuous Integration is now ‘standard’ in IT organisations – One organisation I have been working with in the last 5 years is now performing more than 80,000 builds a day.Continuous Testing is the logical extension to Continuous Integration; if the build succeeded, then why not automatically test it as well? Continuous Deployment is also a logical progression, but one that carries more caution – as the scheduling of the release may be too important to handle automatically
Serena is unique in offering a best-in-class Release Control System and Release Automation System. You can see some of the comments from our customers, noting how Serena’s solution help with quality, speed, and satisfaction.
A good release control system is like your air traffic control tower. Imagine an airport without a control tower. The planes might take off and land more quickly for a while if they don’t have to check with anyone, but is that what you want? A release control system provides the control tower for your software release, allowing you to understand what is happening with the release and providing a system of coordination between all the people involved. It provides visibility, but it should also do things like record events for compliance, enable collaboration, flexibility, have multiplatform support, and integrate with existing tools.
Adding a release automation system is another way to improve your release process. Release automation allows you to create efficiency and quality in your release process by converting ad hoc scripts and human process into a repeatable and executable procedure.