Still moving onwards with my DevOps learning, Day 7 sees me powering through the end of section 2 and completing the readings of Section 3 – Connecting the Circle. If we recall that the chapters in Section 2 for Establishing a pipeline remaining were 10 and 11, with Section 3 chapters 12 – 15

So today I have managed to have a bumper read through Chapters 10 to 15!

PaperBack Edition: https://amzn.to/3gEXquL

Chapters 10-15, finishing off section 2 and moving into the Connecting the Circles chapters of Section 3. We are really starting to get into the weeds of DevOps.

What have I learned?

Lets do this!

Chapter 10 – Automating Tests Prior to Release

• Testing is not optional, working our way to the utopia of CI/CD test code must be written and maintained
  • To ensure code logic does what it needs to do
  • To discover errors/bugs in code
  • To verify that previous functionality hasn’t changed with new code
• Automate Your Tests, review the areas that are:
  • Repetitive
  • Labour intensive
  • Prone to defects
  • Mission is to create an automated test suite that ensures mission critical code is tested and good for customers
• Test in Difference Environments, there is no standard for naming test areas but generally you might have the following environments:
  • Local – Developers workstation
  • Development – Multiple working versions of code, does the code play well with other components?
  • Testing – Ensure code is free from security concerns, ensure that the GUI or user experience is what is expected
  • Staging – Does the code meet or exceed business requirements?
  • Production – If there are problems with your code, this is where you have the most to lose if you haven’t found the issues by the time you get here!
• Going Beyond Unit Testing, ensure your development lifecycle includes time for the following:
  • Developing test cases
  • Writing automated tests
  • Running manual tests (if still required)
  • Making adjustments
  • Unit Tests – Testing the functions of your code
  • Integration Tests – Do all the pieces work together?
  • Regression Tests – After changes, does the code behave the same?
  • Visual tests – Does everything look the same?
  • Performance test
  • Security Testing
• Continuous Testing, ensuring your code is constantly passing through an automated testing suite to check for errors and bugs to help speed up the process. This wont happen overnight, small steady changes is the way!

Chapter 11 – Deploying a Product

• Releasing code, overloaded term, subtle differences in nuance around the words ‘Release’ Build’ ‘Ship’ can mean the same, or subtly different things, make sure you know what each term means for your team for now they all mean the same!
• Integrate and Deliver Continuously
• Benefit from CI/CD, some benefits include
  • Thorough automated testing
  • Accelerated feedback loop
  • Decreased interpersonal conflict
  • Reliable deploy process
• Implementing CI/CD
  • Has its routes in Agile and is an iterative process.
  • Continuous Integration, write automated tests for every feature, set up a CI server, update developer habits to merge changes at least once a day if not more often
  • Continuous Delivery, this is a step up from CI, so must have a strong foundation in CI first, automated releases, maybe consider ‘feature flags’ to push production code but hide features from sections of your audience
  • Continuous Deployment, a step up from Continuous Delivery, code is automatically put into production, ensure you have a strong relationship with automated testing and a strong culture of testing, document new features, ensure coordination with other departments
• Managing Deployments
  • Automate the right way
  • Versioning
  • Semantic versioning
  • Versioning for continuous deployment
  • Track application packaging
• Mitigate failure
  • Rolling back – always plan for this
  • Fixing forward – want to avoid this
• Democratise Deployments
  • Share information
  • Avoid having the one ‘expert’ that has key knowledge
  • CI/CD is absolutely the end goal, but the journey is by far more important!
  • Its fine to include human gates in a CI/CD pipeline
• Choose a Deployment Style
  • You may hear the term ‘NoOps’ as in a deployment can take place with No Operations personnel, this is foolish. No matter how much you abstract the infrastructure from your developer, infrastructure knowledge will still be required.
  • Blue – Green – The idea of having current and staging release in different deployment slots and your routing engine changes from one to the other. Roll back can be completed if necessary at the routing engine.
  • Schrodinger’s Canary – The idea that you use the blue/green deployment slot approach and point a small subset of your production traffic at the new deployment release and monitor for problems, slowly increase the traffic until all production traffic hits new release.
  • Rolling the dice – A rolling deployment one server at a time until all servers are updated.
  • Toggle feature flags – Turning features on or off for difference groups of your customer base.
• Monitor your systems
  • Understand telemetry
  • Record Behaviour
  • SLA – Service Level Agreement
  • SLI – Service Level Indicator
  • SLO – Service Level Objective

Section 3 – Connecting the Circuit

Chapter 12 – Implementing Rapid Iteration

• Prioritise the important
  • 1 – Important and Urgent – Crises and failures, certain deadlines. Avoid manufactured crises.
  • 2 – Important and Not Urgent – Training, Reading, Networking, Building relationships, reducing bottlenecks, long term planning, practicing failure.
  • 3 – Urgent and Not Important – Unscheduled interruptions, taps on shoulder, phone calls, some meetings
  • 4 – Not Urgent and Not Important – Browsing, social media watching TV. Schedule down time for these tasks, they should not form part of your day otherwise. Not good for work or personal development.
• Increase Velocity
  • Important to size work
  • Teams performance is more than speed
• Improving performance
  • Deployment frequency
  • Lead Time
  • Mean Time To Recover (MTTR)
  • Change Failure
• Eliminate Perfection
• Design small teams – 2 pizza team (4-6 people is sweet spot) – Ensure number of communications channels is low
• Track your work
• Reduce friction
• Humanize alerting

Chapter 13 – Creating Feedback Loops around the Customer

Is the age of the MBA CEO over? Are Engineering teams the future of company leadership? It may seem so!

• Creating a customer feedback process – Build, Measure, Learn (Repeat)
• Create a feedback loop – Receive, Analyse, Communicate, Change (Repeat)
• Collect Feedback
  • Satisfaction Surveys
  • Case Studies
  • Dogfooding
  • Ask for continuous feedback
  • NPS (Net Promotor Score) – 1 Question – Would you recommend this product to a friend (10,9 = Promotors, 8,7 = Passives, Below 7 = Detractors)
  • Find a rhythm – Ask, Listen, Analyse, Follow Up, Categorise and track, communicate with product, repeat!

Chapter 14 – DevOps is not a team (Except when it is)

• Forming DevOps Teams
  • DevOps has no defacto structure
  • Approach any reorg with openness and flexibility
  • Assign your teams Vision!!!!
• Aligning Functional Teams
• Dedicating a DevOps Team
• Create cross functional product teams
• Interview Quickly, (but not too quickly)
• Decide on Job titles
• Recruiting Never ends
  • Finding the right folks
  • Passing along great candidates
• Evaluating Technical Ability
  • Whiteboarding revisited, its DevOps, remember the principles of sharing and openness, this should be the same in interview
  • Offer Take-Home tests
  • Reviewing code
• Firing Fast (Employee types to look out for)
  • The Jerk
  • The Martyr
  • The Underperformer

Chapter 15 – Empowering Engineers

• Scaling Engineering Teams with DevOps
  • Three stages of a company – Startup, Late stage startup/Mid Sized, Enterprise, differing approaches to empowerment
  • Very much akin to Spartans, Mongols and Romans
  • Spartans were known for living to fight for themselves, lived for war and to prove themselves from a young age, much like the enthusiasm and drive of a startup.
  • The Mongols had rules and respect was introduced for other religions and beliefs, order was in place much like a mid sized business
  • The Romans built an empire with hundreds of thousands of communications channels, this is akin to an Enterprise.
• Motivating Engineers
  • Research Motivation – Autonomy, Mastery, Purpose
  • DevOpsing Motivation
  • Avoid reliance on Extrinsic motivations, look for intrinsic
  • Make work fun
  • Allow Engineers to choose their teams
• Measure Motivation

Review and position

Again, such an intriguing and interesting view primarily on the people elements, how teams are formed, the basis of what might work well or not has its foundations in the DevOps methodology. Ensure teams are built, KPI’s are measured for continuous improvement and not for incentives. Hiring the right people quickly, act quickly on performance issues.

Im now well over half way through this book and although the DevOps Principles on occasion are specifically talking about code and the creation of, the principles can be equally applied at any level. They seem familiar and coherent, its interesting to put the authors perspective of how thigs should be ordered for potentially the best outcomes.

Really enjoying the learnings from this book and deffinatley elements I can reflect on my own approaches to work.

Next up – Section 4 – Practicing Kaizen, the art of continuous Improvement. I shall be kicking on this this section over the next day or so!

100DaysOfCloud Overview

My Main ReadMe Page is all set up with a bit about me!

The guys at 100DaysofCloud have set up the GitHub repo to be cloned and also have a great repo containing ideas and areas to collaborate on: https://github.com/100DaysOfCloud/100DaysOfCloudIdeas

My Github Journey tracker can be found here: https://github.com/jonnychipz/100DaysOfCloud

Please Watch/Star my repo and feel free to comment of contribute to anything I push! I really look forward to hearing from anyone who is going to jump on the journey around the same time as me! Lets see where I get to in 100 days!

I would encourage others to jump on this journey, I’m not sure that I will be able to commit every day for 100 days, but as long as I can complete 100 days that will be great!