Register for free ebook DL: DevOps for Dummies 3rd Edition
or read the book here:
Beyond the book refs:
» » IBM DevOps Solution: ibm.com/devops
» » DevOps — the IBM approach (white paper): ibm.biz/BdEnBz
» » The Software Edge (study): ibm.co/156KdoO
» » Adopting the IBM DevOps Approach (article): ibm.biz/adoptingdevops
» » DevOps Services for Bluemix (service): bluemix.net
What is DevOps
DevOps short for Development and Operations. It is an approach based on lean and agile principles in which business owners and the development, operations, and quality assurance departments collaborate to deliver software in a continuous manner that enables the business to more quickly seize market opportunities. Some say it is for practitioners only; others say it revolves around the cloud. It is a business-driven software delivery approach that takes a new or enhanced business capability from an idea all the way to production, providing business value.
You need participation from stakeholders beyond just dev and ops teams. A true DevOps approach includes lines of business, practitioners, execs, partners, suppliers etc.
DvO (DevOps) is essential in today’s world. Enterprises must be agile and lean to respond to rapidly changing customer demands, market conditions, competition or regulation.
Understanding the Business Need for DvO
Orgs want to create better innovative apps/services to solve business problems. They may want to address internal business problems such as a better CRM or help customers with a new mobile app.
Many orgs are not successful with software projects and this is due to challenges with software dev and delivery. Only 25% of enterprises believe their teams are effective. This execution gap leads to missed business opportunities.
This problem is further amplified by major shift in types of apps that businesses are required to deliver from systems of record to systems of engagement.
Systems of record are traditional applications that function as a record with large data or transactions. These are reliable and stable and don’t change often. New releases are twice per year.
Systems of engagement mobile and newer web apps support system of record applications. Customers can access directly and use to interact with the business. These apps must be easy to use, high performance, capable of rapid change to address customer changing needs and evolving market.
DvO applies agile and lean principles across the entire SW supply chain. Enables business to maximize the speed of del. of product/service. It improves the way business delivers value to customers so its essential business process not just an IT capability.
It provides significant ROI in 3 areas:
Enhanced customer experience – builds customer loyalty an increased market share. Business must obtain and respond to cust. feedback. Required mechanism to get fast feedback from all stakeholders customers, lines of business, users, suppliers, partners and so on.
Increased capacity to innovate
Faster time to value – involves developing a culture, practices and automation that allow for fast, efficient, and reliable sw delivery through to production. DvO when adopted as a business capability provides the tools and culture required to facilitate efficient release planning, predictability and success.
DvO principles are still evolving. Here are some of them:
Develop and test against production like systems
This is from the DvO concept shift left where operations concerns move earlier in the sw delivery life cycle towards development. The goal is to allow QA teams to develop and test against production like systems. This is so the application performs well before its ready for deployment. This allows operations team to see early in the cycle how the environment behaves and tests the actual app delivery process itself.
Deploy with repeatable, reliable processes
Allows development and operations to support an agile (or at least iterative) software development process all the way to production. Automation is key to create processes that are iterative, frequent, repeatable and reliable.
Monitor and validate operational quality
Monitoring should also move earlier in the lifecycle by requiring automated testing to be done early and often in the life cycle to monitor fuctional and non-functional characteristics of the application. When an app is deployed and tested, quality metrics should be captured and analysed. Frequent monitoring provides early warning about operational and quality issues that may occur in production.
These metrics should be captured in a format that all business stakeholders can understand and use.
Amplify feedback loops
The goal is to react and make changes more rapidly. In sw delivery this requires an organisation to get quick feedback and then learn rapidly from every action it takes. This principle calls for orgs to create comms channels that allow all stakeholders to access and act on feedback.
– Development may act by adjusting its project plans
– Production may act by enhancing the production environments.
– Business may act by modifying its release plans.
Devops capabilities are broad and span the sw del. lifecycle. Where an organisation starts with Devops depends on its business objectives and goals. What challenge its trying to address and what gaps in the sw del. capabilities need to be filled.
Devops reference architecture provides a template of a proven solution by using a set of preferred methods and capabilities. This helps practitioners access and use the guidelines, directives and other material that they need to architect or design a Devops platform that includes people, processes and technology.
This Devops reference architecture proposes the following four sets of adoption paths:
Steer, Develop/Test, Deploy, Operate
Business goals based on customer feedback (Continuous business planning). Traditional ways of product delivery are slow and depend on custom development and manual processes. Teams operate in silos and information is therefore fragmented and inconsistent. They also struggle to incorporate feedback that should inform the priorities of investments and then to collaborate as an organisation to drive execution in a continuous delivery model.
For some teams, planning is viewed as a governance overhead that’s intrusive and slows them down instead of an activity that enables them to deliver value with speed. Faster delivery provides greater business agility, but you need to manage speed with the trust and confidence that what is delivered is the right thing. You can’t deliver sw at speed if you don’t trust the accuracy of your business goals, your measurements and your platforms.
Devops helps to reconcile these competing perspectives, helping teams collaboratively establish business goals and continuously change them based on customer feedback, thereby improving agility and business outcomes. They can also identify and reduce waste in the dev process. This leads to more efficiency and reduced costs.
This path involves collaborative development and continuous testing. It forms the core dev and QA capabilities. Sw delivery in an enterprise involve large numbers of teams inc. lines of business owners, business analysts, enterprise and sw architects, devs, QA, practitioners, operations personnel, security specialists, suppliers and partners. Practitioners from these teams work on multiple platforms and may be spread across multiple locations. Collaborative development enables these practitioners to work together by providing a common set of practices and a common platform they can use to create and deliver sw.
One more capability inc in collaborative development is continuous integration. Sw devs continuously or frequently integrate their work with other members of the dev team.
This was made popular by Agile movement. Devs regularly integrate work with the rest of the devs and then test the integrated work. If there are complex systems or services then devs integrate their work with those systems and services. This leads to early discovery and exposure of integration risks. In complex systems it exposes known and unknown risks both technical and schedule related.
CI has several goals enable ongoing testing and verification of code, validate code integrated with other devs and components of app functions and performs as designed, continuously test the app being developed.
This means testing earlier and continuously across the life cycle, which reduces costs, shortens testing cycles and achieves continuous feedback on quality. This is known as shift left testing, which stresses integration of development and testing to ensure quality is built in as soon as possible and not something left later. This is done by adopting capabilities like automated testing and service virtualisation. This is a new capability for simulation of production like environments and makes continuous testing feasible.
The deploy adoption path is where most root capabilities of devops originated. Continuous release and deployment take the concept of CI to the next step. The delivery pipeline allows continuous deployment of sw to qa and then to production in an efficient automated manner. The goal of continuous release and deployment is to release new features to customers and users as soon as possible. Most of the core tools and processes of devops are used for CI, CT, CR and CD.
This adoption path includes 2 practices allows businesses to monitor how releases are performing in prod and to receive feedback from customers. This allows it to react in an agile manner and change the business plan as necessary.
Continuous monitoring provides data and metrics to operations, qa, dev, lines of business personnel and other stakeholders about apps at different stages of the life cycle. These are not limited prod. These metrics allow stakeholders to react by enhancing/changing the features being delivered and/or the business plans required to deliver them.
The 2 most important types of info that sw del. team can get are data about how customers use the app and feedback that those customers provide upon using the app. New tech allows businesses to capture customer behavior and paint points right as they use the app. This continuous feedback loop is essential to devops allowing businesses to be more agile and responsive to customer needs.
Adopting any new capability requires a plan that inc. people, process and technology.
First to create a culture is getting everyone in the same direction working towards the same goal which means identifying common business objectives for the team and org as a whole. Important to get team towards business outcomes rather than conflicting team incentives. When people know the common goal they are working toward and how their progress towards it will be measured the less challenges exist from teams or practitioners who have their own priorities. Devops isn’t the goal it helps you reach them.
Identify bottlenecks in the delivery pipeline
The biggest sources of inefficiencies in the delivery pipeline have been categorised as:
unnecessary overhead (repeat comms about same info or knowledge)
unnecessary rework (defects being uncovered in testing or prod forcing assignments back to the dev team)
over production (functionality developed that wasn’t required)
One of the biggest bottlenecks in delivery pipeline is deploying infrastructure. The adoption of devops approach increases the speed of app delivery and makes infrastructure respond more quickly. This is where software defined environments enable you to capture infrastructure as a kind of programmable and repeatable pattern therefore accelerating deployments.
People in Devops
Devops is a cultural movement all about people. An organisation may have the most efficient processes or automated tools possible but these are useless without the people who must execute those processes and use those tools. Building a culture is the core of devops adoption.
A devops culture is characterised by collaboration across roles, focus on business instead of departmental objectives, trust and high value placed on learning through experimentation. Measuring culture is extremely difficult. You could do a survey on team morale and attitudes but these have a high error rate as teams are usually small. You can take an indirect measure by tracking how often a dev team member reaches out to a member of an operations or qa team to collaborate on resolving an issue without going through official channels or multiple layers of management. Collaboration and comms across stakeholders is the culture of devops.
Building a culture isn’t like adopting a new process or tool. It requires social engineering of teams of people each with unique predispositions, experiences and biases. This diversity can make culture building challenging and difficult.
Lean and Agile transformation practices such as Scaled Agile Framework (SAFe), Disciplined Agile Delivery (DAD) and Scrum are at the core of devops. If the org already has these then it can be easier to adopt Devops culture. Building a devops culture requires leaders to work with their tam and create an environment and culture of collaborating and sharing. Leaders must remove any self imposed barriers to cooperation. Typical measurements reward operations teams for uptime and stability, reward devs for new features delivered but they pit these groups against each other. Operations know the best protection for production is to accept no changes and the devs have little incentive to focus on quality. Replace these measurements with shared responsibility for delivering new capabilities quickly and safely.
The leaders of the org should further encourage collaboration by improving visibility. Establishing a common set of collaboration tools is essential especially when teams are distributed and cannot work in person. Giving all stakeholders visibility into a projects goals and status is crucial for building a devops culture based on trust and collaboration. Sometimes the devops culture requires people to change if they are unwilling they can be reassigned.
Some orgs such as netflix don’t have separate dev and ops teams instead a singe NoOps team owns both sets of responsibilities. Other orgs have succeeded with Devops liaison teams which resolve any conflicts and promote collaboration. The team could be existing tools or process group or a new team consisting of reps of all teams that have a stake in the app being delivered. If you do have a devops team the most important thing is that it functions as a center of excellence that facilitates collaboration without adding a new layer of bureaucracy or becoming the team that owns addressing all devops related problems. This would defeat the purpose.
Process in Devops
People need to be doing the right processes and in the right way. We discuss some of the key processes. Devops can be seen as a business process. A collection of activities or tasks that produces a specific result for its customers. This business process involves taking the idea that is identified by business owners through the development and testing into production. It isn’t easy but the process should be captured in a process flow that is already used to deliver capabilities. Then you can identify areas of improvement, by improving processes themselves and by introducing automation.
A set of activities designed to manage and track change by identifying work procedures that are likely to change and the processes used to implement that change. This is an inherent part of the broader devops process flow. Orgs that have adopted life cycle management (ALM) already have well defined and probably automated change management process in place.
This should include processes that allow the following:
Work item management, configurable work item work flows, project config management, planning (agile and iterative), role based artifact access control
Traditional change approaches tend to be limited to change request and defect management with limited capability to trace events between the change requests or defects and the associated code or requirements. These approaches don’t provide work item management across the life cycle or built in capability to trace all types of assets. Devops requires all stakeholders to be able to view and collaborate on all changes across the sw dev life cycle.
Devops or ALM change management includes processes that provide work item management for all projects, tasks and associated assets not just the ones affected by the change requests or defects. it allows work items to be linked to all artifacts, project assets and other work items that are created, modified, referenced or deleted by any practitioner who works on them. These processes give team members role based access to all change related information and also support iterative and agile project development efforts.
These are specific techniques you need to include when you use Devops:
Continuous improvement, release planning, continuous integration, continuous delivery, continuous testing and continuous monitoring and feedback.
An org should have built in processes to identify areas of improvement as the org matures and learns from the processes it has adopted. Many businesses have process improvement teams that work on improving processes based on observations and lessons learned. Others allow the teams that adopt the processes to self assess and make their own process improvement paths. Any of these methods can be used but the goal is to enable continuous improvement.
Is a critical business function driven by business needs to offer capabilities to customers and the timelines of these needs. Therefore businesses require well defined release planning and management processes that drive release road maps, project plans, and delivery schedules as well as end to end traceability across these processes.
Most companies currently use spreadsheets for this and have long meetings with all stakeholders across the business to track all business needs applications under development, their development status and release plans. Well defined processes and automation however eliminate the need for those spreadsheets and meetings and enable streamlined and more importantly predictable releases. Using lean and agile practices also results in smaller more frequent releases permitting enhanced focus on quality.
Adds a lot of value. Teams of devs can deliver sw in an agile manner. Each team integrates work with others and then gets validated. Continuous integration reduces risk and identifies issues earlier in the sw dev life cycle.
CI leads to Continuous delivery the process of automating deployment of sw to testing, system testing, staging and production environments. Some orgs stop at production those using devops use the same automated process in all environments to improve efficiency and reduce risk introduced by inconsistent processes.
In test environments automating configuration refreshing test data and then deploying the sw to the test environment followed by execution of automated tests speeds feedback cycles of test results back to development.
Adopting continuous delivery is typically the most critical part of adopting devops. to many devops practitioners devops is limited to continuous delivery so most tools promoted address only this process. however devops is a much broader in scope. Continuous delivery is an essential component of devops but not the only component.
Based on the orgs business needs you may choose to adopt another of the processes or adoption paths described.
These process are needed for continuous testing:
Test environment provisioning and configuration, test ata management, test integration, function, performance and security
In an org QA teams need to determine what processes to adopt for each area. The processes they adopt vary from each project based on individual testing needs and on the requirements of SLA’s. Customer facing apps may need more security testing than internal apps for example. Test environment provisioning and test data management are more important challenges for projects that use agile methodologies and practice continuous integration than they are for projects that use waterfall methodology and test once every few months.
Continuous monitoring and feedback
Customer feedback comes in different forms such as tickets opened by customers, formal change requests, informal complaints and ratings in app stores. Businesses need well defined processes to absorb the feedback from myriad sources and include them in software del plans.These processes need to be agile to adapt to market and regulatory changes.
Feedback also comes from monitoring data from servers running the app, from development, QA and production, or metrics tools embedded in the app that capture user actions. Business needs data capture and data use processes to avoid data overload.
You can measure success of process adoption by seeing whether a set of efficiency and quality metrics is improving over time. This type of measurement must identify the right set of efficiency and quality metrics. These metrics should really matter to the business. Also need to have a baseline against which to measure improvement. There are several well defined frameworks to measure process maturity. For devops specific processes models such as IBM devops maturity model can assess maturity. More info at ibm.biz/adoptingdevops
Technology in DevOps
Enables people to focus on high value creative work while delegating routine tasks to automation. Tech allows teams to leverage and scale time and abilities. If the org is building and maintaining multiple apps everything it does has to be repeatable, in a reliable manner to ensure quality across all apps. It can’t start from scratch for each new bug fix or app. The org has to reuse assets, code, practices to be cost effective and efficient. Standardising automation makes people more effective. Orgs may experience turnover in employees, contractors or resource providers, people may move projects. But a common set of tools allows practitioners to work anywhere and new team members need to learn only one set of tools – a process that is efficient cost effective, repeatable and scalable.
Infrastructure as code
This is a core capability of devops that allows orgs to manage the scale and speed with which environments need to be provisioned and configured to enable continuous del. Infrastructure as code deals with capturing node definitions and configurations as code, software defined environments use technologies that define entire systems made up of multiple nodes not just their configurations, but also their definitions, topologies, roles, relationships, workloads and workload policies and behaviour.
3 kinds of automation tools are available for managing infrastructure as Code (IaC):
Applications or middleware tools these can manage as code both app servers and the apps that run on them. These tools are specialised bundled with libraries of typical automation tasks for the tech they support. They can’t perform low level tasks such as config an os setting but can fully automate server and app level tasks.
Environment and deployment tools can deploy infrastructure configs and application code.
Generic tools aren’t specialised and can be scripted to perform several kinds of tasks, config an OS or virtual physical node to configuring firewall ports. They require more work but can do a greater range of tasks.
Delivery pipeline – consists of stages the app goes through from dev to prod. Figure below shows typical set of stages. these vary from one org to another and one app to another based on an orgs needs, sw delivery process and maturity. The level of automation may also vary. Some orgs fully automate their delivery pipelines, others put sw through manual check and gates due to regulatory or company requirements. You don’t have to address all stages at once you can focus on critical parts and then broaden to include all stages.
Staging environment is as close to production as possible (pre-prod).
In dev developers use tools such as IDE, source control management, work item management, collaboration, unit testing and project planning. These tools are usually cross platform and cross technology.
In build stage code is compiled to create and unit test the binaries to be deployed. Multiple build tools may be used. Dev orgs use build servers for the large no. of builds required to enable CI.
Package repo (asset repo) stores binaries created during build stage. These also store assets associated with binaries such as config files, IaC, files and deployment scripts.
Test environment is where QA, user acceptance and development testing teams do the actual testing. Many tools are used based on QA needs.
Here are a few examples:
Test environment management tools facilitate provisioning and configuring the test environments. These are IaC technologies and cloud provisioning and management tools.
Test data management for an org that wants to enable continuous testing, managing test data is essential. The number of tests that can be run and the frequency are limited to amount of data available for testing and speed at which data can be refreshed.
Test integration, function, performance an security automation tools are available. These should be integrated with a common test asset management tool or repo where all test scenarios, test scripts and associated results can be stored and traceability established back to code, requirements and defects.
Service virtualisation apps are complex and dependent on other apps, app servers, db’s and 3rd party apps and data sources. These components may not be available at test time and costly. Service virtualisation solutions simulate functionality performance behaviour of select components within an app to enable end to end testing of the app as a whole. These tools create stubs (virtual components) of the app and services that are req. for tests to run. The behaviour and performance of the app can be tested as it interacts with these stubs. IBM’s rational test virtualisation server provides such test virtualisation capabilities.
Stage and production environments apps are deployed in these. Tools used in these include environment management and provisioning tools. Tools for infrastructure as code also play a critical role in these stages due to large scale at which environment in these stages exist. With advent of virtualisation and cloud stage and production can be made of hundreds of servers. Monitoring tools allow orgs to monitor deployed apps in production.
Deployment automation and release management – manages automation of app deployment from one stage to next requires specialised tools. These tools perform orchestrated deployments and tack which version is deployed on which node at any stage of build and delivery pipeline. They can also manage config of environments of all stages to which the app components must be deployed. They manage sw components that get deployed, the middleware components and configs that need to be updated, the db components that need to be changed and the config changes to environments.
IBM urban code deploy is one of these tools.
Measuring technology Adoption – Measuring ROI you can measure efficiencies created by automation and automation tools enhance scalability and reliability of tasks. This isn’t always possible with manual tools. Finally using an integrated set of automated tools facilitates collaboration, traceability and improved quality.
Requires coordination across the business, development, qa, and ops teams. Tools allow planning and organising releases, a single collab portal for all stakeholders in a release and provide traceability for release and its components across all stages of build and delivery pipeline.
How cloud accelerates DevOps
Devops and cloud are enablers for each other. The flexibility, resilience, agility and services from cloud allow streamlining an app delivery pipeline hosted in the cloud. Environments from dev, testing to prod can be provisioned and configured as needed. This minimises environment related bottlenecks in the delivery process. Cloud is also used to reduce cost of dev and test environments or provide modern streamlined developer experience. This is an extremely compelling case for cloud adoption with and for Devops.
Using cloud as an enabler for devops
The main goal is to minimise bottlenecks in the delivery pipeline making it more efficient and lean. One of the biggest bottlenecks is environment availability and configuration. Developers and testers can request an environment which can normally take weeks. Another challenge is making the available environment match the production one. This could be as simple as different config for the os or middleware as as much as a different os or middleware type on the dev environments from what is used in production. The lack of availability of environments results in long wait times for practitioners. This mismatch between environments can have quality issues.
Cloud addresses this by speed of environment provisioning. People can self service for on demand environments. Dynamically provision and de-provision environment as needed. Better management and cost reduction. No permanent or static environment. Define and version the environments and they are like production. With tools you can provision environment in cloud and deploy apps as and when needed. Service virtualisation technology allows simulation of services for testing without having to provision real instance of the services.
Cloud without devops means not leveraging the benefits of the cloud.
Deploying cloud app includes deploying the app and configuring the environment. This is known as full stack deployment. This can also be done separately. By combining it maximises the benefits of deploying to the cloud. You can capture cloud environment definition and topology as a blueprint then map app components and configs to the nodes defined in the cloud environment. After the environment is setup further app configs and changes can be continuously deployed to the environment as updates. Or you can have full stack deployments where environments and associated apps are always provisioned together as one deployable asset. In this case no updates are made to the existing environment.
Choosing a cloud service model
You need to decide what to hand over to the cloud and what yo want to take care of yourself.
IaaS Infrastructure as a Service
This method the cloud provides the capabilities, service to manage the virtual infrastructure. the install, patching, management of the OS, middleware, data and app remain your responsibility. Which model to use depends on how devops is adopted. For IaaS model the org is responsible for managing the entire del. pipeline. Al the tools and integrations become orgs responsibility inc. acquiring the right tool set and making sure they are integrated.
Separation of Duties
When using devops on IaaS cloud the key question is to define the separation of duties between cloud and app deployment tool. Which tool is responsible for what. An easy way is to look at it as slow and fast moving assets in the cloud stack. Below shows different layers of an app stack from the os, storage and network all the way to the application.
The app, data and middleware config layers are fast moving in nature. These change often because the app its data and usage iterate. This velocity of change can be very high for an app under development. The lower layers include middleware (app server, db and so on), the os, storage and they don’t change as often. Updating and re-provisioning all the layers for a simple change that just impacts the app, its content or config isn’t efficient, it makes sense to separate the duties of these fast versus slow moving layers between an app deployment and cloud management tool. The fast moving layers are managed and automated by the app deployment tool and slow moving y the cloud management sw provided by the cloud platform.
PaaS – Platform as a Service
With this model you are responsible for application and data. All other capabilities are provided by the cloud platform as services. The result is a significantly enhanced practitioner experience for the app delivery teams. The app dev and testing tools are now available as services on the platform that can be accessed. The org is no longer responsible for managing the del. pipeline. This allows users to focus exclusively on rapidly delivering apps. A PaaS platform can provide the app delivery pipeline as a set of services. The team does not need to worry about how the services are hosted and delivered to them. These devops services include:
web based IDE, build as a service, planning and task management as a service, security scanning as a service, deploy as a service and monitoring and analytics as a service. The platform also provides scalable runtime environments for apps running in diff environments in the del. life cycle.
Hybrid cloud has become common where multiple cloud tech coexist or where cloud and physical infrastructure coexists.
Cloud and physical infrastructure is very common. Some apps such as mainframe and data heavy systems of record do not get migrated to cloud because of tech or cost constraints. In many cases the physical can’t migrate to cloud overnight and is a gradual process.
On premise and off premise cloud – An org may use off premise (public or virtual private) for some apps and workloads and an on premise cloud (private) cloud for others. An example would be an org using low cost off premise cloud for dev environments and on premise self managed cloud in its own dc for all prod workloads.
Iaas and Paas: This is when some customers have PaaS model for some workloads, new innovative systems of engagement type apps for example and IaaS for more traditional systems of record workloads.
For devops hybrid cloud introduces new challenges as app delivery pipelines span across complex hybrid cloud and physical environments. Examples of hybrid cloud environments:
An org may use public cloud for dev, testing and other non production environments while using an on premise cloud or even physical infrastructure for prod.
an org may have some systems of engagement apps deployed to a cloud environment while systems of record apps that provide back end services for the core business apps may still reside on physical infrastructure such as a mainframe.
Orgs may leverage a public PaaS for experimentation with innovative apps and want to bring them to a private cloud, once an experiment succeeds.
Orgs may want to have portability of app workloads across multiple cloud platforms in order to ensure vendor lock in doesn’t exist or to provide the ability to deploy critical workloads across multiple cloud vendors.
The core requirement for adopting devops with hybrid cloud approach is the need for app deployment across these multiple cloud and physical environments.
Using Devops to solve new challenges
devops originated in so called born on the web companies such as etsy, flickr and netflix. These companies while solving complex tech challenges at a very large scale had fairly simple architectures unlike large enterprises that grew around legacy systems and/or through acquisitions and mergers, with complex multi technology systems that had to work together. These challenges were further aggravated by demands put on modern enterprises by new technologies like mobile and app delivery models such as sw supply chains.
App lifecycle management manages the life of an app as it evolves from idea (a business need) to an app that’s deployed and eventually under maintenance. Devops as an end to end capability makes ALM the fundamental concept underlying the devops process. Devops broadens the scope of ALM to include business owners, customers, and operations as part of the process.
The devops develop/test adoption path aligns closely with ALM capabilities of requirements management, change management, version control, traceability and test management. Other ALM capabilities such as tracking and planning occur part of the steer adoption path and dashboards and reporting are included in the Operate adoption path.
Lean and Agile dev are the underpinnings of the devops approach. Waste reduction for more efficient teams is one of the results. Efficiency and repetition of best practices lead to shorter dev cycles allowing teams to be more innovative and responsive thereby increasing customer value.Scaling lean and agile beyond the dev team across to other teams in the entire product and sw del life cycle is core to the devops approach.
Many popular frameworks are available to help scale agile. Scaled Agile Framework (SAFe) and Disciplined Agile Delivery (DAD). Some orgs have also been successful at scaling the Scrum process to very large teams. The purpose of these frameworks is to provide a method for adopting agile at the enterprise level. This means considering not just code but also including architecture, project funding, governance of the processes and roles required by management, applying the very same lean and agile principles that have worked well at the team level.
Multiple tier apps
In a large IT Shop you would find multiple tier apps that span many platforms each with its own unique dev process, tools and skill requirements. These multi tier systems often integrate apps on the web, desktop and mobile apps on the front end and back end systems such as packaged apps, data warehouse systems, apps running on mainframes and midrange systems. Managing and releasing on these can be overwhelming.
Increasing use of outsourcing and strategic partnerships to supply skills and capabilities to an enterprise, software supply chains are becoming the norm. A supply chain is a system of organisations, people, technology, activities, information and resources involved in moving a product or service from supplier to customer. The various suppliers in the chain may be internal or external to the enterprise. An org with supply chain model of delivering sw adopting devops can be a challenge as the relationships among suppliers are managed more by contracts and SLA than by collaboration and communication. This org can still adopt devops.
The core project teams retain ownership of the planning and measurement capabilities with other capabilities being shared among the other suppliers. In the delivery pipeline diff suppliers may own diff stages of pipeline. Using a common tool set and asset repository is therefore essential. A work item management tool for example provides reporting on all items being worked on by all suppliers and transfer of ownership of work items across suppliers.
The next big step for devops is Inter of things the systems or embedded devices often referred to as continuous engineering. Operations in continuous engineering is replaced by hw or systems engineers who design and build custom hw for devices. Collaboration between the development and testing teams and the systems engineer is crucial to ensure that hw and sw are developed and delivered in a coordinated manner despite hw and sw dev needing to follow diff delivery cycles.
IBM’s own adoption of devops and sw can be found on jazz.net
The executive role
To address the cultural dynamic of adopting devops:
Select the right leader who can pull together different viewpoints and bring team to common set of objectives, inhibitors, process changes and decisions on where to start first.
Involve stakeholders the leadership, management, individual contributors need to support the changes.There must be champions of change in each department.
Measure improvements and outcomes is critical to have set of key metrics that incorporate both the needed efficiencies and business outcomes. These goals and measurements should set a high bar and hold people accountable but they shouldn’t cause disengagement.
Understanding the inefficiencies and measuring improvements in each area builds momentum for change. As a leader it’s important to understand the real dynamics of how the change is taking hold in the team. Spending time having one on one conversations and regular face to face with the technical teams, management, business leaders helps to gauge the guy in of the team, their perspective on the inhibitors and equally important an opportunity for management to share perspectives on priorities and progress.
Infrastructure as code allows developers to write scripts to configure required infrastructure for their app as part of their app code. In the past this was done by a system administrator or an operations person. Puppet Chef and IBM Urban code deploy with patterns are examples of the new category of infrastructure automation tools that make infrastructure as code a practical reality.
Experimenting rapidly – the concept of continuous delivery includes not only sw development activities, such as continuous integration and deployment but also learning which is best achieved through frequent experimentation and measuring the results.
When features and functions are added to an app you never know for certain if the customer will receive the expected or intended benefits. So that’s why its important to experiment early and often, get feedback from customers as to what actually works for them and discard features that have little benefit or are even a hindrance.
See Chapter 6 for IBM’s adoption of DevOps improvements made and metrics that were used.