1. OpenMake Dynamic DevOps
Dynamic DevOps Roadmap
Build, Release, Deploy for the Enterprise

2. Mission and Difference
A unified DevOps standard (build, release, deploy) designed for the large organization and flexes to meet each team’s current maturity level with a clear roadmap for achieving higher levels of maturity and compliance in the future.
We deliver a higher level of maturity throughout the SDLC process, as compared to a project based DevOps approach.
We facilitate the sharing and management of the technology stack between development & operations
Our solutions simplify the coordination of the many moving parts involved in an enterprise release from build through deploy.
We are the only solution (commercial or open) that delivers an enterprise standard that simplifies the DevOps “handoff” using a model-driven process from build through deploy.

3. Our Market Large Organizations which include:
Public Sector
Banks, Finance
Insurance
Defense
Retail
Largely sold through OEMs
Our customers are loyal because:
We standardize the build and release activities of the SDLC
We support multiple languages and platforms
We incorporate Database updates with code changes starting at the Build
We support multiple development tools and version control repositories
We are expert in helping Development teams write large applications with multiple levels of dependencies
We support home-grown scripts and give them a method for moving beyond scripts
We deliver faster more efficient methods of managing smaller less risky releases
We meet auditing standards through our Build Audit that matches binaries to Source

4. Remote Artifact Repository
Challenge We Address
Multiplied by the number of teams and releases.
Remote Artifact Repository
Continuous Build using one-off Build Scripts
local
Artifact Repository
Source Repository
Server Configuration Management
Change Request
Driven by Developer One-Off Scripts
Continuous Build using one-off Build Scripts
local
Artifact Repository
Source Repository
Server Configuration Management
Change Request
Driven by Developer One-Off Scripts
Continuous Build using one-off Build Scripts
local
Artifact Repository
Source Repository
Server Configuration Management
Change Request
Driven by Developer One-Off Scripts
Continuous Build using one-off Build Scripts
local
Artifact Repository
Source Repository
Server Configuration Management
Change Request
Driven by Developer One-Off Scripts
Continuous Deploy using One-off Deploy Scripts
Approvals
The DevOps process for an individual project team looks very similar to the process for larger teams. However, the devil is in the details. Developers create their code, using what 3rd party and low level components they need. This information is managed in the black box of one-off build scripts written for a particular release and lifecycle state. Some of the technology components may be downloaded automatically from a external “artifact” repository. Other components may come from a local “artifact” repository. This information determines the server configuration. It is 100% developer driven, without input or notification to the operations side of the business. In fact, some of the 3rd party artifacts are downloaded in such a way that even the developers may not understand what pieces and parts have been archived into their final binaries. This is a “feature” of the artifact repositories. The workflow engine of Jenkins will execute the build and deploy scripts supporting an efficient process for developers to update code, build the code, deploy the binaries and run their test. Developers retain control over the process, often providing operations just enough information to re-execute their deploy scripts in a Production environment. Tools such as Jenkin, Maven Repository, Maven Scripts, Chef or Puppet are used to complete the process.
This is what is needed across the enterprise with the addition of more transparency, less scripting and shared knowledge between development and operations. The problem for the enterprise is taking this developer driven model, centralizing it and implementing it across all teams and all states of the lifecycle. There are too many scripted components to sustain this across the enterprise. In addition, the intelligence that the process generates is not exposed, leaving much critical information hidden in scripts and log files. A DevOps process built for the purpose of a single team can work fine, but managing this for hundreds of teams is not sustainable. The money saved in Open Source solutions is spent in the manual work needed for keeping these systems running. It is redundant, non-transparent, inconsistent and difficult to maintain for a single operations team.
Development Control
Operations Control
DEV
TEST
UAT
PROD

5. DevOps Maturity Process Improvement Metrics SDLC Automation
Meister and Release Engineer
Process Improvement
Key Achievements
Ongoing Improvement
End to End
Delivery
Standardization
Process
Heroes
Jenkins with Scripts.
Metrics
SDLC
Automation
Team based Automation
Scripting
Level 0: (Scripting) Success depends on the competence and heroics of the people writing the build and deploy scripts
Level 1: (Team Based Automation) Scripts are executed under a CI process like Jenkins, build, deploy and testing logs are centralized.
Level 2: (SDLC Automation) Scripts are replaced with a model-driven framework of build and deploy activities. Critical data hidden in the scripts are now available for performing dependency management, component analysis and improved release packaging.
Level 3: (Metrics) Actionable reports are delivered across teams.
Level 4: (Process Improvement) Optimization of end-to-end processes can be analyzed with continuous process improvement.
Level 0
Level 1
Level 2
Level 3
Level 4
Delivery Levels
Copyright © 2010 CA. All rights reserved.

6. DevOps for the Enterprise
Maven/Nexus
DevOps for the Enterprise
Mojo
Jira, Service Desk, HP ALM
SVN, Git, CC, Dimensions, Harvest, etc
Meister
Cloud Builder
Mojo
The ultimate solution for the large organization is a dynamic and model driven process that can provide the same functionality with more intelligence and less developer scripting. It is critical to establish a method for developers and operations to share knowledge about the binary and release configurations as early in the process as possible while leaving in place the basic functionality needed by both agile and waterfall driven development methodologies.
OpenMake Meister is a Build Automation solution that manages the binary configuration by generating, based on models, what developers would normally code using Ant/Maven or Make. This generation allows the operations team to share in the control of the 3rd party components and artifacts that are included in the binary configuration. This is a critical starting point as binary configuration determines the server configurations. Dependency Management, impact analysis, and binary configuration management is 100% automated to a level that is transparent and simplified using a reusable, model driven process. This allows information to be easily communicated between
development teams who share code,
the development teams and the DBAs,
as well as between development and operations.
This high-level of automation and generation helps standardize the shared code, reuse and the maintenance of the underlying technology stack across the enterprise. Creating this level of exposure at the build level is extremely helpful in agile environments where incremental processing is encouraged. It allows for the acceleration of the compile/link/archive step and the planning of updates to server configurations long before they are needed. No other Build Automation solution performs the creation of binaries or allows for the operations team to share in the control of the components and artifacts used as part of the binary.
The output of the Build is the input to the Deploy. OpenMake Deploy+ is a Continuous Deploy Server that standardizes, based on deploy models, how releases are performed. The Meister generated information is used to pre-validate a release and plan for the needed updates to server environment variables, database changes and operation level software updates. These all become a Release Package that moves across the lifecycle as a complete unit. Deploy+ manages Servers and Environments simplifying the job of the operations team who must support many platforms and applications.
Orchestrating this process is OpenMake Mojo, the central Continuous Integration server and binary repository, that also allows for the plug-in of external tools and processes that make each installation unique.
Further extending the DevOps process is OpenMake CloudBuilder. CloudBuilder allows for development teams to include server provisioning as part of their Continuous Integration process. This is important as it allows them to easily request an particular environment for building and testing. Access to test and production environment is essential to allow developers to perform test for environments other than what is currently the Development environment.
Release Engineer
Release Engineer

7. What’s New in Dynamic DevOps 7.51
Release Engineer (ARA features)
Centralizes the management, configuration, and reuse of all Release and Deploy elements for the large enterprise.
Formally Deploy+
New features around Packaging and Reuse
Beta Release Feb 2014
GA Release May 26th 2014

8. Why we are better
It’s flexible “Domain” design allows Operations to define release standards that can be inherited and customized specifically for each project team.
Highly Reusable
It supports multi-tiered platforms with no reliance on any agent technology.
Mid-tier, Tandem, Stratus and AS400

9. Release Engineer Highlights
Coordination & Collaboration
User Roles
Developers
Environment Managers
Release Managers
Application Release
Component versioning
Packaging
Env. Configurations
Dependencies
Deployment
Infrastructure/Environments
Deployment Models (no scripting needed)
Server Role (Database, Application, Load Balancer)
Server Mgmt (physical, Virtualized Cloud)

10. Release Engineer – ARA Features
Defines Global Components and Versions
Application’s inherit Components,
Applications can be a “Component” to a Dependent Application
WebSphere for Example
Application “Deploy” Workflow
Application Versions are “promoted”
Calendar and Scheduling
Collaboration

11. Release Engineer – Deploy Features
Defines the Environment and Servers
Defines the Server Roles
Database,
Application
Manages Deploy Models
IIS, WebSphere, Tomcat
Performs Agentless Delivery
Rollback
Incremental “Roll Forward”

12. Key Benefits
Model Driven, Domain Architecture delivers a high level of reuse resulting in:
Less work for Release Team allowing them to support more Dev teams with the same number of staff.
Reduces Risk with Incremental Deployments
Minimizing changes minimizes release “risk.” Our “Roll Forward” compares with previous Releases and delivers just the changes.
One For All
Supports Cross Platforms and languages. (Not designed with just Java in mind)
Release Team uses one solution for all platforms.
OpenMake Software -Confidential

13. Pricing Twice the functionality and half the price of the “big guys.”
Site License $65,000
Includes both the Release Automation and Deployment features.
OpenMake Software -Confidential

14. OMS Dynamic DevOps - a Complete Solution
Planning & Requirements
Management
Business Technology
IT Portfolio Management
Analyze Change Impact & Cost
Meister
Development Management
Quality Control Management
Operations
Production
Control
Create/Store Binaries
Continuous Build/Deploy
Project Management
Code
Eclipse/.Net/
Oracle
Manage & Track Source
Low Risk Production Releases
Environment Mgmt
Release Engineer
Component
Packaging
Release
Engineer
Audit and Validate
Delivery
Approval
DevOps Ecosystem