Onwards with my DevOps learning, Day 6 sees me moving onto the 2nd Part of the DevOps for Dummies book. After arranging the kids who decide that they all feel like going out with friends, a nice 2 hour drive ends with me grabbing a couple of hours with my book and reruns of Impractical Jokers on the TV. What more do you need for a Bank Holiday Sunday!
Today I have managed to read through Chapters 6 to 9!
PaperBack Edition: https://amzn.to/3gEXquL
Chapters 6-9 have been recognisable and intriguing at the same time..
What have I learned?
Ok so to start, the preface of this section 2 sets the scene around each chapter, essentially introducing the concept of what the Software Product lifecycle is etc. Here is my break down of each chapter and some key take-aways for me and how it relates to my thoughts:
Chapter 6 – Embracing the new Development Lifecycle
This chapter starts by discussing the traditional Development lifecycle as a series of tasks in a linear fashion:
- Traditional Lifecycle – Planning, Designing, Coding, Testing, Deploying
- This lifecycle is typical of Waterfall Project Management methodology with a beginning and an end.
- Agile Project Management Methodology takes the end of the Deploying task and attaches it to the beginning of the planning task, essentially creating a circle of never ending continuous improvement in the Lifecycle.
- DevOps, being based on Agile takes this ‘Loop’ and aims to include all parties and stakeholders cantered around the Product lifecycle and aims to arm them all with access to all information, to encourage collaboration and communication between teams.
- Shifting Operations ‘Left’ – Thinking about infrastructure – The term ‘shifting left’ essentially aims to bring any stakeholder in the development process closer to the developer to ensure that no delays are incurred during product release stages. Shifting Ops to the Left is the basic principle of DevOps, bringing IT Operations folk closer together with Developer folk. Other functions can be shifted left, i.e. Security, Testing and QA etc.
- Mimic production environment through staging, the importance of a staging area.
Chapter 7 – Planning Ahead
This chapter essentially covers topics such as Planning in a DevOps organisation, the ways to gather information, the importance and goal of creating a Minimum Viable Product (MVP) and also the importance of creating User stories.
- Moving beyond Agile – DevOps has its roots in the Agile methodologies. With its 12 principles:
- Satisfy customer by continuously delivering beneficial software
- Accept and welcome changing requirements along the process
- Deliver working software frequently
- Enable developers and business stakeholders to work in constant daily cooperation
- Trust your engineers to get work done
- Convey information face to face
- Realise that working software is the most important measure of success and progress
- Maintain a constant pace of work
- Strive for technical excellence
- Allow teams to self organise for the best product
- Regularly reflect as a team on how to become more effective and adjust together accordingly.
- Forecasting Challenges
- At the start of a project, generally everyone with enthusiastic , relaxed and open to suggestion.
- Culture must reflect openness.
- Assumptions about others may derail progress of the Development Lifecycle.
- Assumption of malice, lack of curiosity and defensive egos in any team can be huge threats to working through a DevOps transformation.
- Identify Project Challenges and constraints – EVERY project has some!
- Scope, Deadline, Quality and Budget are four typical constraints
- Limitations may include, resource, compliance requirements, market trends etc.
- Schedule limitations, are you having to hit a marketing target, or product launch?
- Budget constraints, can you get head count authorised or finance arranged to work on a project? Is one senior Developer an option over 2 less senior developers? Infrastructure costs to build and develop on? How much would it cost every week if deadlines were not met? Intersection of cost and time.
- Gather Requirements
- Share business objectives
- Create user stories
- Set scope
- Design a MVP
- MVP’s are critical for DevOps
- Identify the problem for the MVP to solve
- Identify your Customer
- Scrutinise Competition
- Prioritise Features – Features cant live without, nice to have, ones that don’t matter, make sure MVP is only features cant live without.
- Design User experience
- Test Hypothesis
- Alpha or Beta testing?
- Determining your Customer by Designing a Persona
- ‘Everyone’ is not a persona
- The more detailed you can make a persona the better
- A persona is the identification of your audience
- Design a Persona
- Ensure basic information is captures, name, job title, gender, salary, location. Also ensure that marginalised groups are represented (i.e. ensure that someone who may identify as non-binary is represented in the requirements gathering)
- This about the deeper and more emotional aspects of a person, simple points like salary and location may aim to frame product, but the more human aspect of a persona will aid in influencing decision making.
- Education, Goals, Challenges, Values, Fears etc. are all items of a persona that aid deeper understanding of a person.
Chapter 8 – Designing Features from a DevOps Perspective
- Adopting DevOps is a commitment to infecting every person, process, and product with the core philosophies of DevOps.
- Constructing your Design
- Look out for ‘Anti-Patterns’ to DevOps, processes that work against the mind set.
- Linear processes with no feedback loop or circuit for continuous improvement are examples of Anti-Patterns
- Ensure continuous sharing of knowledge
- Ensure people have knowledge across each part of the development lifecycle even though their focus may be primarily in one. i.e. Code-Build-Test-Release-Maintain, encourage collaboration and knowledge sharing.
- Invite Feedback from Engineering
- Allow time for analysis
- Consider appointing a special team of design engineers or architects to create High Level designs for development by engineering.
- Designing For DevOps
- You should design and build updateable software –
- You should constantly improve your software
- Your software should support learning
- Document your software
- Architect code for the 6 Capabilities of DevOps:
- Document Design Decisions – You WILL forget why you made a decision, explain why you chose one path over another, ensure this is shared and everyone can access these design decisions.
- Avoid Architecture Pitfalls
- Understand your full stack
- Isolate components
- Don’t make difficult choices configurable (Keep it simple)
- Document configuration
- Keep your system dynamic
- Use a log aggregator
- Avoid calling infrastructure API’s from your app
- Go with the crowd
Chapter 9 – Developing Code
This chapter has been created with the operations person in mind, which is great for me!
- Communicating about code
- Ensure code reviews are conducted
- If team doesn’t communicate well, introduce steps to encourage those not communicating. Speech coaching confidence.
- Impostor Syndrome, the feeling that you are ‘not the expert’ and will be ‘found out’. This feeling is typical of high achieving technical people. If you feel less valuable or talented that your colleagues which in turn may stop you from speaking.
- Impostor Syndrome may also remove you of your ability to teach if you feel that your knowledge is inferior. Whatever you know, however basic you think it is, will be valuable to somebody, so sharing is key, if you aren’t the expert……. so what! Share what you know!
- Engineer for Errors
- Ensure error handling is paramount with human readable errors that are handles elegantly with instructions to the use ron what to do next.
- This helps the user and the developer know where the error originated.
- Write Maintainable Code:
- Write Testing Code
- Debug code using debuggers, either using stop/break points to understand how the code runs by stepping through or over code blocks
- Write Logging Code, where testing or debugging at runtime in production is difficult, a log can unearth where things go wrong.
- Write Immutable code
- Create readable code, comment properly and ensure it can be read not just by machines, but by the humans that write it.
- Programming Pattern
- Object Orientated Programming
- Functional Programming
- Choosing a Language
- Choose a language based on the following criteria, be wary of engineering not willing to move between languages, they may be too comfortable!
- Avoid Anti-Patterns – Describing behaviours that highlight poor practise, typical Anti-patterns include
- Design by committee
- God objects
- Cargo culting
- Law of the hammer
- Bleeding edge
- Over engineering
- Spaghetti code
- Premature optimisation
- Vendor Lock-in
- DevOpsing Development
- Writing clean code
- Understand the business
- Listen to others
- Focus on the right things
- Get comfortable with being uncomfortable
- Establishing Good Practices
- Organise Source Code
- Write tests
- Document features
- Peer reviewed code
Review and position
That takes me to the end of my readings for today. I think in summary that although personally I have been out of a day to day role focussed on Development, my position and role fits the vast majority of principles and approaches identified in the section so far.
It’s actually encouraging for me to know that a lot of the process around Agile and DevOps has at some point infultrated my working practice, and for me I am fortunate to have a working environment with a lot of the described best practices in place. Having said that, obviously there is always room for improvements to be made.
I take comfort and enjoyement that this simple process of documenting my readings and learnings and sharing them via my blog in itself is paramount to DevOps principles, regardless if anyone is actually reading this blog, that is’nt the point. The sheer act of writing and publishing your findings to invite comment and discussion is in itself the point!
I really hope I’ve got a few readers lurking out there, its really interesting watching the stats of my wordpress site, my twitter feed and linked in feed fluctuate based on when I post and time of day. For me this is the process of DevOps implementation and mind shift, using this #100DaysOfCloud as the process for me seems to be working after such a small amount of time.
I’m really enjoying this process, however do occasionally look at the list of things i’m racking up on my list to work through over this process, it can be a little daunting at times! Anyhow, that’s me for now, please if you are following me, give me a comment or a like to show that you are there and not just a stat query on Google analytics!!!
Until tomorrow !!
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!