The document discusses DevOps practices and team structures. It notes that DevOps emphasizes automation and having development teams take on operational responsibilities. Teams should be small to allow for quick decision making. Key roles include the team lead, members, service owner, reliability engineer, gatekeeper, and DevOps engineer. Coordination is needed both within and across teams to ensure integration and avoid duplication. Architectural decisions can help with cross-team coordination.

1. Devops
1

2. 2
DevOps Perspective
• DevOps comes in multiple flavors and with different degrees of
variation from current practice, but two themes run consistently
through the different flavors: automation and the
responsibilities of the development team.

3. 3
Automation
• The steps from build and testing through execution can all be
automated to some degree.

4. 4
Development Team Responsibilities
• Automation will reduce the incidence of errors and will shorten
the time to deployment.
• If the development team accepts DevOps responsibilities, that is,
it delivers, supports, and maintains the service, then there is less
need to transfer knowledge to the operations and support staff
since all of the necessary knowledge is resident in the
development team.

5. 5
DevOps and Agile
• One of the characterizations of DevOps emphasizes the
relationship of DevOps practices to agile practices.
Disciplined Agile Delivery phases for each release

6. 6
DevOps practices impact all three phases.
1. Inception phase. During the inception phase, release planning
and initial requirements specification are done.
2. Construction phase.
During the construction phase, key elements of the DevOps
practices are the management of the code branches, the use of
continuous integration and continuous deployment, and
incorporation of test cases for automated testing.
A new element is the integrated and automated connection
between construction and transition activities.

7. 7
3. Transition phase.
In the transition phase, the solution is deployed and the
development team is responsible for the deployment,
monitoring the process of the deployment, deciding
whether to roll back and when, and monitoring the
execution after deployment.

8. 8
Team Structure
Team Size
• Exact team size recommendation differs from one
methodology to another, all agree that the size of the
team should be relatively small.
• Amazon has a “two pizza rule.”
• That is, no team should be larger than can be fed from
two pizzas. Although there is a fair bit of ambiguity in
this rule—how big the pizzas are, how hungry the
members of the team are—the intent is clear.
• The advantages of small teams are:

9. 9
i) They can make decisions quickly.
In every meeting, attendees wish to express their
opinions.
The smaller the number of attendees at the meeting,
the fewer the number of opinions expressed and the
less time spent hearing differing opinions.
Consequently, the opinions can be expressed and a
consensus(agreement) arrived at faster than with a
large team.

10. 10
ii) It is easier to fashion a small number of people into a
coherent unit than a large number.
A coherent(Systematic/orderly) unit is one in which
everyone understands and subscribes to a common set of
goals for the team.
iii) It is easier for individuals to express an opinion or
idea in front of a small group than in front of a large
one.

11. 11
• The disadvantage of a small team is that some tasks
are larger than can be accomplished by a small number
of individuals. In this case the task has to be broken up
into smaller pieces, each given to a different team, and
the different pieces need to work together sufficiently
well to accomplish the larger task. To achieve this, the
teams need to coordinate.

12. 12
Team Roles
Two of the roles in the team from Scott Ambler’s
description of roles in an agile team.
• Team lead. This role, called “Scrum Master” in Scrum
or team coach or project lead in other methods, is
responsible for facilitating the team, obtaining resources
for it, and protecting it from problems.
 This role encompasses the soft skills of project
management but not the technical ones such as planning
and scheduling, activities which are better left to the team
as a whole.

13. 13
• Team member.
 This role, sometimes referred to as developer or
programmer, is responsible for the creation and delivery
of a system.
 This includes modeling, programming, testing, and
release activities, as well as others.

14. 14
• Additional roles in a team executing a DevOps process
consist of
service owner,
reliability engineer,
gatekeeper, and
DevOps engineer.

15. 15
Service Owner
• The service owner is the role on the team responsible
for outside coordination.
• The service owner participates in
system-wide requirements activities,
prioritizes work items for the team, and
provides the team with information both from the clients
of the team’s service and about services provided to the
team.
• The ability to communicate both with other
stakeholders and with other members of the team is a
key requirement for the service owner.

16. 16
Reliability Engineer
• The reliability engineer has several responsibilities.
i) First, the reliability engineer monitors the service in
the time period immediately subsequent to the
deployment. This may involve the use of canaries (live
testing of a small number of nodes) and a wide variety
of metrics taken from the service.
ii) Second, the reliability engineer is the point of contact
for problems with the service during its execution. This
means being on call for services that require high
availability. Google calls this role “Site Reliability
Engineer.”

17. 17
Gatekeeper
• The gatekeeper decides whether to allow a version of a
service or a portion of a service through “the gate” to the
next step.
• The gatekeeper may rely on comprehensive testing
results and have a checklist to use to make this decision
and may consult with others but, fundamentally, the
responsibility for allowing code or a service to move on
through the deployment pipeline belongs to the
gatekeeper.

18. 18
DevOps Engineer
• The DevOps engineer role is responsible for the care and
feeding of the various tools used in the DevOps tool chain.

19. 19
Coordination
• Coordination as “the organization of the different
elements of a complex body or activity so as to enable
them to work together effectively.”
• Goal of DevOps is to minimize coordination in order
to reduce the time to market.
Two of the reasons to coordinate are,
first, that the pieces developed by the various teams will
work together and,
second, to avoid duplication of effort.

20. 20
Forms of Coordination
• Coordination mechanisms have different attributes.
• Direct—the individuals coordinating know each other
(e.g., team members).
• Indirect—the coordination mechanism is aimed at an
audience known only by its characterization (e.g.,
system administrators).
• Persistent—the coordination artifacts are available after
the moment of the coordination (e.g., documents, e-mail,
bulletin boards).

21. 21
• Ephemeral—the coordination, per se, produces no
artifacts (e.g., face to face meetings, conversations,
telephone/video conferencing). Ephemeral coordination
can be made persistent through the use of human or
mechanical recorders.
• Synchronous—individuals are coordinating in real time,
(e.g., face to face).
• Asynchronous—individuals are not coordinating in real
time (e.g., documents, e-mail).

22. 22
Team Coordination
• Team coordination mechanisms are of two types
human processes and
automated processes.
The DevOps human processes are adopted from agile
processes and are designed for high-bandwidth
coordination with limited persistence.

23. 23
• Automated team coordination mechanisms are
designed to protect team members from interference of
their and others’ activities (version control and
configuration management systems), to automate
repetitive tasks (continuous integration and deployment),
and to speed up error detection and reporting (automated
unit, integration, acceptance, and live production tests).
One goal is to provide feedback to the developers as
quickly as possible.

24. 24
Cross-team Coordination
• Examining the release process activities again makes it clear that
cross-team coordination is the most time-consuming factor.
• Coordination must occur with customers, stakeholders, other
development teams, and operations.
• Therefore, DevOps processes attempt to minimize this
coordination as much as possible.
• From the development team’s perspective, there are three types of
cross-team coordination: upstream coordination with
stakeholders and customers, downstream coordination with
operations, and cross-stream coordination with other
development teams.

25. 25
There are two reasons for a development team to
coordinate with other development teams—to ensure that
the code developed by one team works well with the code
developed by another and to avoid duplication of effort.

26. 26
Making the code pieces work together
• One method for supporting the independent work of different
development teams while simplifying the integration of this work
is to have a software architecture. An architecture for the system
being developed will help make the pieces work together.
Six of these design decisions are:

27. 27
a)Allocation of responsibilities.
In DevOps processes, general responsibilities are specified
in the architecture but specific responsibilities are
determined at the initiation of each iteration.
b) Coordination model.
The coordination model describes how the components of
an architecture coordinate at runtime. Having a single
coordination model for all elements removes the necessity
of coordination about the coordination model.

28. 28
c. Data model. As with responsibilities, the data model
objects and their life cycle are specified in the architecture
but refinements may occur at iteration initiation.
d. Management of resources. The resources to be
managed are determined by the architecture. The limits on
these resources (e.g., buffer size or thread pool size) may
be determined during iteration initiation or through system-
wide policies specified in the architecture.

29. 29
e. Mapping among architectural elements. The least
coordination is required among teams if these mappings
are specified in the architecture and in the work
assignments for the teams.
f. Binding time decisions. These are specified in the
overall architecture. Many runtime binding values will be
specified through configuration parameters, and we will
discuss the management of the configuration parameters.

30. 30
2. Avoiding duplication of effort. Avoiding duplication of
effort and encouraging reuse is another argument for
coordination among development teams.