Introduction to DevOps

Seite 1

Social Coding Principles

What is social coding?

open source practice

All repositories are public

everyone is encoraged to contribute

Anarchy controlled via pull requests

Social coding solution

DAOFI

Pair Programming

taken from extreme programmer:

driver: typing

navigator: reviewing

two programmers

switch every 20 minutes

Higher code quality

defects found earlier

lower maintenance costs

skills transfer

two sets of eye on every line of code

broader understanding of the code base

Social coding is coding that is done communally. A form of social coding is pair programming in which programming is done in pairs with a driver and navigator. PP results has numerous benefits as it produces higher code quality, defects found earlier, skills transfer, and a broader understanding of the codebase.

Seite 2

Git Repository Guidelines

How does the git feature branch workflow supports social coding?

Guidelines:

create a separate Git repo for every component

1 microservice/component : 1 repos

Create a new branch for every Issue

there is a master branch and features branches

Use pull requests to merge to master

Every pull request is an opportunity for a code review

Git Feature Branch workflow

Clone GHub Repo to Local Repo

Create a Local Branch in your Local Repo

Push code changes to Remote Branch

Raise a Pull Request to have your code reviewed in the Remote Repo.

Merge to master after the Remote repo's code has been reviewed and approved for merging.

Seite 3

Working in Small Batches

a concept from lean manufacturing

faster feedback

supports experimentation

minimizes waste

deliver faster

single piece flow

review the example in working in small batches

measuring the size of batches

feature size supports frequent releases

features should be completed in a single sprint (in a week or less)

features are a step toward a goal, so keep them small.

Key concepts

smaller batches = faster feedback cycles AND faster delivery

Seite 4

Minimum Viable Product

Lesson Objective:

What is the minimum viable product (mvp)?

It is not phase 1 of a project.

it is an experiment to test a hypothesis and learn

focused on learning

at the end of each mvp, you should be able to decide whether you want to pivot or persevere.

a tool for learning

experiment may fail and that's okay

failure leads to understanding

What did you learn from your failure?

What will you do differently?

How should an mvp be used to give the customer what they really want?

the mvp is used to generate a product that is based on the customer requirements in order to get feedback and learn more about what the customer want. I would have to review the example in IBM DevOps and Software Engineering - Minimum Viable Product.

Seite 5

Test-Driven Development

Learning Objectives:

Define Test Driven Development (TDD)

writing test cases is important to proving that your code functions as intended.

test cases drive the design of code

write test first, then write code to pass test

keeps focused on process.

code is of no use if you cannot call it.

gives you the callers perspective

Summary: Test Driven Development is a development methodology in which test cases are what drive the design of the product (software). This methodology is beneficial because it gives you an idea what you want the code to look like for the users.

Question: What is TDD?

One sentence answer (OSA): Test Driven Development is a development methodology in which test cases are what drive the design of the product (software).

***The first thing to do when you clone a repo from Github is to run the test cases in order to determine if the code is already broken or if you broke it.

Describe how TDD produces higher-quality code

Describe the Red, Green, Refactor workflow

Basic TDD workflow:

Red: Write a test case that fails (fail)

Green: Write a test case that passes (pass)

Blue: Improve code quality (refactor)

How can I apply this workflow?

When can I apply this workflow?

I can apply this workflow with exrlty - 820

Where can I apply this workflow?

Describe the importance of TDD for DevOps

it saves time when developing

code faster and with more confidence

it ensures the code is working as expected

it ensures that future changes don't break your code

in order to create a CI/CD pipeline, all testing must be automated.

Seite 6

Behavior Driven Development (BDD)

Learning objectives:

Define behavior driven development (BDD)

describes the system behavior from an outside perspective

great for integration testing

uses syntax that both developers and stakeholders can easily understand

Explain how BDD can drive customer expectations

BDD = outside / in = integration testing -> verification

workflow:

explore the problem domain and describe the behavior

document the behavior using Gherkin syntax

Gherkin:

easy to understand

Given When Then:

Given: some context

When: some event happens

Then: some testable outcome

And: more context, events, or outcomes

Example:

Feature: Returns go to stock

As a store owner

I need to add items back to stock when they're returned.

So that I can keep track of my stock on hand.

Scenario 1: Refunded items should be returned to stock

Given that a customer previously bought a black sweater from me

And I have 3 black sweaters in stock

When they return the black sweater for a refund

Then I should have 4 black sweaters in stock.

Gherkin for acceptance criteria:

add acceptance criteria for every user story

Use gherkin to do that Indisputable definition of done.

Understandable by everyone

originally called cucumber

Use BDD tools to run those scenarios

One document that's both the specification and the tests.

TDD = inside / out = unit testing -> validation

Describe key benefits of bdd

self-documenting

improves communication

more precise guidance

provides common syntax

Application:

I will use do exercise two of coding challenges in java using gherkins syntax as part of my test plan.

Seite 7

Cloud Native Microservices

Learning Objectives:

Think differently about application design

a software designed as a collection of small services

What is the difference between being stateful and stateless

A microservice is a software architecture that is comprised of a collection of small services.

cloud native means something is born on the cloud.

Therefore, cloud native microservices is a software architecture comprised of a collection of small services born on the cloud.

Think cloud native

heroku paved the way for cnp

12 factor app

each service maintains its own database

resilience through horizontal scaling

what is scaling?

what is horizontal scaling?

What is vertical scaling?

failing instances are killed and respawned.

devops pipeline

Martin Fowler and James Lewis

Monolith:

Frontend

Middleware

Backend

Microservices

What is a load balancer?

What is a balancer?

What is a load?

***revisit this lesson

Seite 8

Designing for Failure

Learning objectives:

recognize the importance of failure

failure is important because it provides feedback about something from which we gain information to learn and improve whatever it is that we strive to achieve.

explain the importance of quick recovery from failure

recovery from failure is important factor in becoming robust and antifragile. The recovery time reduces loss in time, energy, and money, and stress.

describe how retry patterns, circuit breaker patterns, and bulkhead patterns help make applications resistant to failure.

Retry patterns work by retrying failed operations.

Circuit breaker patterns are designed to avoid cascading failures.--a failure that produces a chain reaction of ensuing failures in a system.

Bulkhead patterns can be used to isolate failing services.

Chaos engineering is deliberately causing services to fail to see how other services are affected.

How can I implement this patterns?

What service can I build to make

Seite 9

Summary

Social coding is coding as a community and public repositories and pair programming result in higher code quality.

Working in small batches reduces waste and means quickly delivering something useful to the customer.

Minimum viable product is as much about delivery as it is about building what the customer really desires.

Test driven development is writing the test for the code you wish you had, then writing the code to make the test pass. It allows you to develop faster and with more confidence.

Behavior driven development focuses on the behavior of the system from the outside in. It looks at the system as a consumer of it.

Behavior driven development improves communication by using an approachable syntax that developers and stakeholders can understand.

Microservices are built around business capabilities and are independently deployable by fully automated deployment machinery.

Cloud native architecture enables independently deployable microservices that take advantage of horizontal scaling and result in more resilient services.

Failure is inevitable, so we design for failure rather than trying to avoid failure.

It is important to embrace failure and quickly recover when failures happen.

Seite 10

Review

Minimum Viable Product Video

Cloud Native Microservices

Seite 11

Software Engineering vs. Civil Engineering

Learning Objectives

How is software engineering different from civil engineering?

silos and largely unchanging

a projected to be completed and move-on

software stack is updated constantly

new features are being added

system behaviors are changing

Maintain stable, lasting teams

Describe at least one way that software engineering is constantly changing.

software engineering is changing constantly, and one way that it is doing so is by the software stack, new features being added, and system behavior changes.

Describe at least 1 way that the PM model does not work

The PM model treats software like a project to be completed and then moved-on from. This causes a problem because the dev team does not feel any ownership of the code and as a result does not feel responsible for the upkeep of the project.

Seite 12

Required DevOps Behaviors

Learning Objectives:

What is at least one difference between traditional ops and DevOps?

what does diametrically mean?

Dev = Innovation

Ops = stable

How does Dev and Ops view one another?

Manuallly implemented changes (why is this a problem?)

Lack of back-out plans

Lack of testing

Environments that don't look like production

All-or-nothing changes

change windows

implemented by people furthest away from the application

Ops just cuts and pastes from run book

List the required DevOps behavior?

shared ownership and high collaboration

risk management by embracing change

ephemeral infrastructure as code

automated self-service

feedback loops and data-driven responses

Seite 13

Infrastructure as Code

Learning objectives:

define infrastructure as code

what is server drift?

how to build a test environment?

What is parallel infrastructure?

dev = development

prod = production

what is rolling updates?

describe ephemeral infrastructure,

describe immutable delivery via containers

Seite 14

Continuous Integration

Learning objectives:

conti

Seite 15

Organizing for DevOps

Learning Objectives:

Describe the organizational impact of DevOps

Describe team structure in DevOps

Describe how making everyone responsible for success leads to success

Organizational Impact of DevOps

Learning Objective: Describe the organizational impact of DevOps

Organizational Impact of DevOps

How does organizational structure impact DevOps?

organizational structure is important to a devops team because it can affect the productivity of the team. There are some factors to consider regarding the following:

team size: teams need to be small in order to be agile. Being agile is the first tenet of DevOps. If a team cannot move fast and fluidly, then more than likely it is not DevOps.

team dedication: teams most be dedicated to work one sprint at a time in order to increase focus.

So, to answer the question, organizational structure will determine if you are getting the full benefits of DevOps. The organization should work small, be dedicated, be cross-functional, and self-organizing.

What is Conway's Law?

Conways law is a dictum that states that organization will organize themselves around the communication structure of the team.

This means that an organization with three teams will produce a three tier application or that a 4 tier organization will produce a 4 tier application.

What is the optimal organization for DevOps teams?

the optimal way to organize a DevOps team is around business domains because this allows the team to cross-functional and focus on their service and features from end-to-end so that they cannot work in silos and not feel the consequences of their own work.