Working DevOps

Taylorism and Working in Silos

Working DevOps:

• Culture of teaming and collaboration

• Agile development as a shared discipline

• Automate relentlessly

• Push smaller releases faster

  Taylorism:

• Adoption of command and control management

• Organizations divided into functional silos

• Decision-making is separated from work

Impact of Taylorism on IT:

Software development is bespoke:

• Software development is NOT like assembling automobiles

• Most of the parts don’t exist, yet

• Software development is craft work

• Taylorism is not appropriate for craft work

  Abandon Command and Control:

• Command and control is not Agile

• Stop working in silos

• Let your people amaze you

Software Engineering vs. Civil Engineering

Software engineering is organic:

• Software stack is constantly updated

• New features are being added

• System behavior changes over time

• Yet we treat software engineering like a civil engineering project

  The project model is flawed:

• The project model doesn’t work for software development

• Treat software development like product development

• Encourage ownership and understanding

• Software engineering is not civil engineering

• Maintain stable, lasting teams

Required DevOps Behaviors

Diametrically opposed views:

• Enterprises see “new” as complex and time-consuming
• DevOps delivers a continual series of small changes
• These cannot survive traditional overheads

A clash of work culture:

The no-win scenario:

• Development wants innovation
• Operations wants stability

Operations view of development:

• Development teams throw dead cats over the wall

• Manually implemented changes

• Lack of back-out plans

• Lack of testing

• Environments that don’t look like production

  Development view of operations:

• All-or-nothing changes

• Change windows in the dead of night

• Implemented by people furthest away from the application

• Ops just cuts and pastes from “runbooks”

  No-win scenario:

• If the website works, the developers get the praise!

• If the website is down, operations gets the blame!

  Required DevOps behaviors:

Infrastructure as Code

• Described an executable textual format

• Configure using that description

• Configuration Management Systems to make this possible (Ansible, puppet etc.)

• Never perform configurations manually

• Use version control

  Ephemeral immutable infrastructure:

• Server drift is a major source of failure

• Servers are cattle not pets

• Infrastructure is transient

• Build through parallel infrastructure

  Immutable delivery via containers:

• Applications are packaged in containers

• Same container that runs in production can be run locally

• Dependencies are contained

• No variance limits side effects

• Rolling updates with immediate roll-back

  Immutable way of working:

• You never make changes to a running container

• You make changes to the image

• Then redeploy a new container

• Keep images up-to-date

Continuous Integration (CI)

CI vs. CD:

• CI/CD is not one thing
• Continuous Integration (CI):
  • Continuously building, testing, and merging to master
• Continuous Delivery (CD):

  • Continuously deploying to a production-like environment

    Traditional Development:

• Devs work in long-lived development branches
• Branches are periodically merged into a release
• Builds are run periodically
• Devs continue to add to the development branch

Continuous Integration

• Devs integrate code often
• Devs work in short-lived feature branches
• Each check-in is verified by an automated build

Changes are kept small:

• Working in small batches

• Committing regularly

• Using pull requests

• Committing all changes daily

  CI automation:

• Build and test every pull request

• Use CI tools that monitor version control

• Test should run after each build

• Never merge a PR with failing tests

  Benefits of CI:

• Faster reaction times to changes

• Reduced code integration risk

• Higher code quality

• The code in version control works

• Master branch is always deployable

Continuous Delivery

“Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time.” — Martin Fowler

Release to production at any time:

• The master branch should always be ready to deploy
• You need a way to know if something will “break the build”
• Deliver every change to a production-like environment

CI/CD pipeline:

• Automated gates that create a pipeline of checks:
  • Unit testing
  • Code quality checks
  • Integration testing
  • Security testing
  • Vulnerability scanning
  • Package signing

A CI/CD pipeline needs:

• A code repository
• A build server
• An integration server
• An artifact repository
• Automatic configuration and deployment

Continuous integration and delivery:

Five key principles:

1. Build quality in
2. Work in small batches
3. Computers perform repetitive tasks, people solve problems
4. Relentlessly pursue continuous improvement
5. Everyone is responsible

CI/CD + Continuous deployment:

How DevOps manages risk:

• Deployment is king
• Deployment is decoupled from activation
• Deployment is not “one size fits all”