DevOps means beyond the high-level vision of tighter and more effective
collaboration between development teams and operations teams.
Here I listed the best practices which we could use for the effectively in DevOps
Practice 1: Active Stakeholder Participation
A fundamental philosophy of DevOps is that developers, operations
staff, and support people must work closely together on a regular basis.
An implication is that they must see one other as important
stakeholders and actively seek to work together. A common practice
within the agile community is "onsite customer," adopted from Extreme
Programming (XP), which motivates agile developers to work closely with
the business. Disciplined agilists take this one step further with the
practice of active stakeholder participation, which says that developers
should work closely with all of their stakeholders, including
operations and support staff--not just business stakeholders. This is a
two-way street: Operations and support staff must also be willing to
work closely with developers.
Practice 2: Automated Testing
Agile software developers are said to be "quality infected" because
of their focus on writing quality code and their desire to test as
often and early as possible. As a result, automated regression testing
is a common practice adopted by agile teams, which is sometimes extended
to test-first approaches such as test-driven development (TDD) and
behavior-driven development (BDD). Because agile teams commonly run
their automated test suites many times a day, and because they fix any
problems they find right away, they enjoy higher levels of quality than
teams that don't. This is good news for operations staff that insists a
solution must be of sufficient quality before approving its release into
production.
Practice 3: Integrated Configuration Management
With an integrated approach to configuration management (CM),
development teams not only apply CM at the solution level as is
customary, they also consider production configuration issues between
their solution and the rest of your organization's infrastructure. This
can be a major change for some developers because they're often used to
thinking about CM only in terms of the solution they are currently
working on.
In a DevOps environment, developers need to be
enterprise-aware and look at the bigger picture. How will their solution
work with and take advantage of other assets in production? Will other
assets leverage the solution being developed? The implication is that
development teams will need to understand, and manage, the full range of
dependencies for their product. Integrated configuration management
enables operations staff to understand the potential impact of a new
release, thereby making it easy to decide when to allow the new release
to occur.
Practice 4: Integrated Change Management
From an IT perspective, change management is the act of ensuring
successful and meaningful evolution of the IT infrastructure to better
support the overall organization. This is tricky enough at a
project-team level because many technologies, and even versions of
similar technologies, will be used in the development of a single
solution. Because DevOps brings the enterprise-level issues associated
with operations into the mix, an integrated change management strategy
can be far more complex, due to the need to consider a large number of
solutions running and interacting in production simultaneously. With
integrated change management, development teams must work closely with
operations teams to understand the implications of any technology
changes at an organization level. This approach depends on the earlier
practices of active stakeholder participation, integrated configuration
management, and automated testing.
Practice 5: Continuous Integration
Continuous integration (CI) is the discipline of building and
validating a project, through automated regression testing and sometimes
code analysis whenever updated code is checked into the version control
system. CI is one of the sexier agile development practices (at least
from a developer's perspective) that is typically associated with
DevOps. CI enables developers to develop a high-quality working solution
safely in small, regular steps by providing immediate feedback on code
defects.
Practice 6: Integrated Deployment Planning
From the point of view of development teams, deployment planning has
always required interaction with an organization's operations staff; in
some cases, via liaison specialists within operations typically called
release engineers. Experienced development teams will do such planning
continuously throughout construction with active stakeholder
participation from development, operations, and support groups. When you
adopt a DevOps strategy, you quickly realize the need to take a
cross-team approach to deployment planning due to the need for
operations staff to work with all of your development teams. This isn't
news to operations staff, but it can be a surprise to development teams
accustomed to working in their own siloed environments. If your team is
not doing this already, you will need to start vying for release slots
in the overall organizational deployment schedule. Furthermore, to
support continuous deployment, release engineers will need to increase
the number of release slots available to agile teams that are
disciplined enough to continuously and consistently meet the quality
requirements for release.
Practice 7: Continuous Deployment
Continuous deployment extends the practice of continuous integration.
With continuous deployment, when your integration is successful in one
sandbox, your changes are automatically promoted to the next sandbox,
and integration is automatically started there. This automatic promotion
continues until the point where any changes must be verified by a
person, typically at the transition point between development and
operations.
Continuous deployment enables development teams to
reduce the time between a new feature being identified and being
deployed into production. It enables the business to be more responsive.
However, continuous deployment increases operational risk by increasing
the potential for defects to be introduced into production when
development teams aren't sufficiently disciplined. Successful
continuous deployment in an enterprise environment requires all the
practices described earlier.
Practice 8: Production Support
In enterprise environments, most application development teams are
working on new releases of a solution that already exists in
production. Not only will they be working on the new release, they will
also have the responsibility of addressing serious production problems.
The development team will often be referred to as "level three support"
for the application because they will be the third (and last) team to be
involved with fixing critical production problems.
Although the need to
do level three production support is common, with the exception of
Kanban and Disciplined Agile Delivery (DAD), many agile methods only
address this effort in passing. An important side effect of this
practice is that it gives developers an appreciation of the kinds of
things that occur in production, providing them with learning
opportunities to improve the way that they design solutions in the
first place.
Practice 9: Application Monitoring
As the name suggests, this is the operational practice of monitoring
running solutions and applications once they are in production.
Technology infrastructure platforms such as operating systems,
application servers, and communication services often provide monitoring
capabilities that can be leveraged by monitoring tools (such as
Microsoft Management Console, IBM Tivoli Monitoring, and jManage).
However, for monitoring application-specific functionality, such as what
user interface (UI) features are being used by given types of users,
instrumentation that is compliant with your organization's monitoring
infrastructure will need to be built into the applications. Development
teams need to be aware of this operational requirement or, better yet,
have access to a framework that makes it straightforward to provide such
instrumentation.
Practice 10: Automated Dashboards
The practice of using automated dashboards is business intelligence
(BI) for IT. There are two aspects to this, development intelligence and
operational intelligence. Development intelligence requires the use of
development tools that are instrumented to generate metrics; for
example, your configuration management (CM) tools already record who
checked in what and when they did it.
Continuous integration tools could
similarly record when a build occurred, how many tests ran, how long
the tests ran, whether the build was successful, how many tests we
successful, and so on. This sort of raw data can then be analyzed and
displayed in automated dashboards.
Operational intelligence is an aspect
of application monitoring discussed previously. With automated
dashboards, an organization's overall metrics overhead can be
dramatically reduced (although not completely eliminated because not
everything can be automated). Automated dashboards provide real-time
insight to an organization's governance teams.
DevOps Is Really About Culture
After describing these critical practices which support DevOps, I
feel the need to emphasize that the primary critical success factor is
to build a collaborative and respectful culture across your entire IT
organization. My experience is that people, and the way that they work
together, are the primary determinant of success when it comes to
adopting an effective DevOps strategy. Unfortunately, it is considerably
more difficult to bring about cultural change in an organization than
it is to adopt a handful of new practices.
