Please note that this article is a note instead of a tutorial
Essential Characteristics of DevOps
DevOps is the practice of development and operation engineers working together during the entire development life cycle, following Lean and Agile principles that allow them to deliver software rapidly and continuously.
DevOps has three dimensions: culture, method, and tools.
The essential characteristics of DevOps include cultural change, automated pipeline, infrastructure as code, microservices, containers, and immutable infrastructure
Decisive Moments of DevOps History
- Patrick Debois, 2007: Dev and Ops work ineffectively and not together
- John Allspaw, 2009: 10+ deploys a day Flickr
- Jez Humble, 2010: Continuous Delivery
- Gene Kim, Jez Humble, Patrick Debois: The DevOps Handbook
Evolution of Methodologies and Tools
Delivery:
flowchart LR
Waterfall --> Agile --> DevOps
Architecture:
flowchart LR
Monoliths --> SOA["Service-oriented Architecture (SOA)"] --> Microservices
Infrastructure:
flowchart LR
PS["Physical Servers"] --> VMs --> Containers
Traditional Waterfall Development
flowchart LR
Requirements --> Design --> Code --> Integration --> Test --> Deploy
- No provisions for changing requirements
- No idea if it works until the end
- Each step ends when the next step begins
- Mistakes found in the later stages are more expensive to fix
- Usually a long time between software releases
- Teams work separately
- People who know the code least deploy it into production
Extreme Programming (XP), Agile, and Beyond
- XP is one of the first Agile methods (origin of Pair programming)
- Agile emphasizes valuing individuals, collaboration, responding to change, adaptive planning, early delivery, and continuous improvement
Social Coding
flowchart
Discuss["Discuss with the repo owner"]
--> Agree["Argee to develop a feature"]
--> Issue["Open an issue and assign it to yourself"]
--> Fork["Fork the code and make changes"]
--> PR["Issue a pull request to review and merge"]
Social coding is an open-source practice, which needs all repositories to be public and everyone is encouraged to contribute. It’s controlled by merge requests.
Pair Programming
Pair programming involves two people: a driver, and a navigator**. The driver types while the navigator is reviewing. Every 20 minutes they switch.
Benefits:
- Higher code quality
- Defects found earlier
- Lower maintenance costs
- Skills transfer
- More people understand the code
Git Repository Guideline
flowchart LR
CRepo -- Clone --> LRepo -- Branch --> LBranch -- Push --> CBranch -- Merge --> CRepo
CRepo["Cloud Repo"]
LRepo["Local Repo"]
LBranch["Local Branch"]
CBranch["Remote Branch"]
- Create separate git repos for every component (microservices)
- Create a new branch for every issue
- Use PR to merge to master
Working on Small Batches
Working in small batches reduces waste and means quickly delivering something useful to the customer.
- From Lean Manufacturing
- Faster feedback
- Supports experimentation
- Minimize waste
- Deliver faster
Minimum Viable Product (MVP)
- A cheap way to test hypotheses
- Focus on learning, not delivery
- At the end of each MVP, decide to pivot or persevere
- MVP may fail, but failure leads to understanding
“We want a car instead of a skateboard, but the red color is cool”
or in Silicon Valley S1E1: the Pied Piper
Test Driven Development (TDD)
“If it’s worth building, it’s worth testing. If it’s not worth testing, why are you wasting your time working on it?”
flowchart TD
REFACTOR --> |Write a test case that fails| RED["Red (Fail)"] -->
|Write code to make it pass| GREEN["Green (Pass)"] -->
|Improve code quality| REFACTOR
- Write tests first and make the test pass
- To create a DevOps CI/CD pipeline, all testing must be automated
Benefits:
- Saves time developing
- Code faster and with more confident
- Ensure the code work as expected
- Ensure the future changes don’t break the code
Behavior Driven Development (BDD)
BDD ensures that you are building the right thing
TDD ensures that you are building the thing right
- Describe the behavior of the system from the outside
- Great for integration testing
- Use syntax that both developers and stakeholders can easily understand
Workflow:
- Explore the problem domain and describe the behavior
- Document the behavior using Gherkin syntax
- Use BDD tools to run those scenarios
Benefits:
- Improve communication
- More precise guidance
- Provide a common syntax
- Self-documenting
- Higher code quality
- Acceptance criteria for user stories
Gherkins
- Given (some context)
- When (some event happens)
- Then (some testable outcome)
- And (more context, events, or outcomes) for continuation
Cloud-Native Microservices
Cloud Native means being born on the cloud, enabling independently deployable microservices that take advantage of horizontal scaling and result in more resilient services.
- A collection of stateless(do not maintain) microservices
- Each service maintains its own database
- Resilience through (To be elastic by) horizontal scaling
- Failing instances are killed and respawned
- Continuous delivery of services
- Microservices are loosely coupled services, designed for scalability and communication with APIs (REST API)
Microservices are built around business capabilities and are independently deployable by fully automated deployment machinery.
Designing for Failure (Patterns)
Failure is inevitable, so we design for failure rather than trying to avoid failure.
- Retry Pattern: retry failed operations, gradually increase request interval
- Circuit Break Pattern: to avoid cascading failures, once failures reach a certain limit or a threshold
- Bulkhead Pattern: isolate failing services
- Chaos Engineering (Monkey Testing): by deliberately killing services, since you cannot know something responds to a failure until it fails