SaltyVagrant

DevOps ‘for Beginners’: Lab 005

2022-10-05T00:00:00+01:00

TL;DR DevOps ‘for Beginners’ stream.

New topic: Basic programming.

Discuss coding versus programming versus software engineering. Why this is important.

Then some basics using Bash scripts, Lua, and Python as examples.

Note: This will be the most basic introduction BUT hopefully we’ll set you on the right course from the start!

Schedule Details

Venue:	Twitch or YouTube (yes, I going to try simultaneous streaming)
Time:	Thursday 6^th October 2022 @ 18:00 UTC

In this stream we will introduce basic coding for DevOps.

If you want to follow along with the lab you should install the following tools:

Then clone the lab¹.

1git clone https://gitlab.com/saltyvagrant.classes/pfs-material.git 
2cd pfs-material 
3vagrant up

Social

Social Media

Reddit https://www.reddit.com/user/saltyvagrant
YouTube https://www.youtube.com/channel/UCjZc6ngNGEIVbFfSWmZDmlw
Twitter https://twitter.com/saltyvagrant
Email saltyvagrant@gmail.com

¹This will take a while to run as it is setting up a substantial development environment. It will seem to freeze showing ‘Running Salt Highstate’, be patient as this can take several minutes even on a fast network/machine, the install pulls several Docker images (among other things).

DevOps ‘for Beginners’: Lab 004

2022-09-23T00:00:00+01:00

TL;DR DevOps ‘for Beginners’ stream.

This stream went off track somewhat into a more general DevOps discussion, but I think it’s still worth watching.

Schedule Details

Venue:	Twitch or YouTube (yes, I going to try simultaneous streaming)
Time:	Thursday 29^th September 2022 @ 18:00 UTC

If you want to follow along with the lab you should install the following tools:

Then clone the lab tag that starts this lab¹ and start the lab.

1git clone --branch lab004 https://gitlab.com/svstreams/cicd.git 
2cd cicd 
3vagrant up

Topics Covered

Broad discussion of DevOps as a career.

Availability

Social

Social Media

Reddit https://www.reddit.com/user/saltyvagrant
YouTube https://www.youtube.com/channel/UCjZc6ngNGEIVbFfSWmZDmlw
Twitter https://twitter.com/saltyvagrant
Email saltyvagrant@gmail.com

¹You will be warned about being on a Detached Head, don’t panic this is expected.

DevOps ‘for Beginners’: Lab 003

2022-09-16T00:00:00+01:00

TL;DR DevOps ‘for Beginners’ stream.

This stream was a Lab continuing the introduction of the ‘backbone’ of DevOps, the CI/CD pipeline.

Schedule Details

Venue:	Twitch
Time:	Thursday 22 ^nd September 2022 @ 18:00 UTC

In this stream we picked up from where we left of last week.

If you want to follow along with the lab you should install the following tools:

Then clone the lab tag that starts this lab¹ and start the lab.

1git clone --branch lab003 https://gitlab.com/svstreams/cicd.git 
2cd cicd 
3vagrant up

Topics Covered

Basic CI pipeline
CI for release versus CD for deploy
Concourse pipeline, resources, tasks, and scripts
Docker (and using dive to inspect images)
Designing your CI build
GitLab (following GitHeb fail)

Availability

Social

Social Media

Reddit https://www.reddit.com/user/saltyvagrant
YouTube https://www.youtube.com/channel/UCjZc6ngNGEIVbFfSWmZDmlw
Twitter https://twitter.com/saltyvagrant
Email saltyvagrant@gmail.com

¹You will be warned about being on a Detached Head, don’t panic this is expected.

DevOps ‘for Beginners’: Lab 002

2022-09-12T00:00:00+01:00

TL;DR DevOps ‘for Beginners’ stream.

This stream is was a Lab continuing the introduction of the ‘backbone’ of DevOps, the CI/CD pipeline.

Schedule Details

Venue:	Twitch
Time:	Thursday 15 ^th September 2022 @ 18:00 UTC

In this stream we picked up from where we left of the previous week.

If you want to follow along with the lab you should install the following tools:

Then clone the lab tag that starts this lab¹ and start the lab.

1git clone --branch lab002 https://gitlab.com/svstreams/cicd.git 
2cd cicd 
3vagrant up

Topics Covered

Bash scripting (refactoring)
Passing environment variables to Vagrant
Concourse CI pipelines and tasks
Docker
Sphinx (and the Sphinx container)

Availability

Social

Social Media

Reddit https://www.reddit.com/user/saltyvagrant
YouTube https://www.youtube.com/channel/UCjZc6ngNGEIVbFfSWmZDmlw
Twitter https://twitter.com/saltyvagrant
Email saltyvagrant@gmail.com

¹You will be warned about being on a Detached Head, don’t panic this is expected.

DevOps ‘for Beginners’: Lab 001

2022-09-06T00:00:00+01:00

TL;DR DevOps ‘for Beginners’ stream.

This stream will be a Lab introducing the ‘backbone’ of DevOps, the CI/CD pipeline.

Schedule Details

Venue:	Twitch
Time:	Thursday 8 ^th September 2022 @ 18:00 UTC

In this stream we will start a lab session and start discussing the backbone to DevOps, the CI/CD pipeline.

If you want to follow along with the lab you should install the following tools:

Topics Covered

Basic Vagrant
Introduction to Infrastructure as Code and the importance of idempotence
Bash scripting
sed
Docker and docker-compose
Concourse-CI
Ports, port forwarding

Availability

Social

Social Media

Reddit https://www.reddit.com/user/saltyvagrant
YouTube https://www.youtube.com/channel/UCjZc6ngNGEIVbFfSWmZDmlw
Twitter https://twitter.com/saltyvagrant
Email saltyvagrant@gmail.com

DevOps ‘for Beginners’

2022-08-31T00:00:00+01:00

TL;DR Presentation introducing DevOps ‘for Beginners’ stream.

What do we mean ‘DevOps’?

DevOps
DevOps Engineer

Definitions

DevOps

Coined in 2009
A philosophy of integrating Development and Operations
Often a Cargo Cult

DevOps lore is that DevOps as we recognise it today was born of a conference talk given by John Allspaw and Paul Hammond titled “10+ Deploys per Day: Dev and Ops Cooperation at Flickr”.

A significant problem is organisations that for DevOps cargo cults. Cargo cults arise from a sort of sympathetic magic thinking. Native islanders during the war witnessed soldiers build airstrips, control towers, radar dishes, etc. They saw food and manufactured goods delivered by aircraft. Once the soldiers left the aircraft stopped landing and the flow of goods stopped. The islanders built facsimiles of the radar equipment, built airstrips, and control towers in preparation for the hoped for return of aircraft along with all they brought. Obviously no aircraft came. The islanders reproduced the form without understanding the function.

Similarly organisations often reproduce the form of DevOps (they create a DevOps team with people holding the title DevOps Engineer) but failing to appreciate the function of DevOps these efforts seldom realise the gains promised.

DevOps Engineer

Job title
NOT agreed upon, but commonly includes:
- Maintain CI/CD
- Care and feeding of infrastructure
- Communicate/coordinate across lifecycle
- Metrics collection and analysis
- Broad knowledge

DevOps beginner is sometimes seen as an oxymoron. This is, I suspect, because people define “DevOps Engineer” as “someone with broad experience of IT systems over many years”. Under this definition one can only agree. However these same people will often council people wanting to start a career in DevOps to first work in development or operations, which to me sounds like advice on beginning DevOps.

Can you step straight into a DevOps Engineer role? Evidence from people who have done just this suggests it is possible, but also very rare. These ‘Junior DevOps Engineer’ roles are sort of apprenticeships.

Core Skills

Problem Solving

The principal skill of any IT professional, but above all in a DevOps Engineer role, is problem solving .

Not any specific technology (trust me, they all date). Learn to think!

Identify the problem
Figure out possible solutions
Liaise with domain experts
Plan and execute solution in controlled manner

What this stream is about

Why this stream?

Use the fundamentals
Teach the ‘hard parts’
Problem solving
Research (finding things out)
Constructive play (experiment)

There are, as people pointed out, plenty a ‘structured video courses’ but these do not teach what I believe to be the important skills. You certainly need to invest time learning at least the basics in a wide variety of the disciplines. Recognise though that it is impossible to be an expert in all areas. Learn enough that you can communicate clearly with domain experts.

The ‘hard parts’ are, by definition hard to teach but important to learn. The best way, IMHO, is practice, practice, practice.

Research: Asking the right (sort) of question. Where to look. How to read.

Availability

Social

Social Media

Reddit https://www.reddit.com/user/saltyvagrant
YouTube https://www.youtube.com/channel/UCjZc6ngNGEIVbFfSWmZDmlw
Twitter https://twitter.com/saltyvagrant
Email saltyvagrant@gmail.com

Core Concepts: Entropy

2022-02-04T00:00:00+00:00

TL;DR Examining the core concept of entropy.

Without the input of effort things tend to decay.

My home requires constant attention. The garden requires attention (at minimum to stop it becoming an overgrown wilderness that would prevent me getting to the front door). Inside it needs regular cleaning and periodic maintenance. If a home is lived in it will degrade without someone maintaining it.

IT systems suffer a similar fate. Without a constant input of effort systems will degrade as changes are applied. This is commonly called ‘bit rot’ in software circles. The proposition is that without taking time to focus exclusively on opposing this entropy our system will degrade, eventually resulting in higher costs to change and maintain the system or worse catastrophic failure.

The essential point being ‘focus exclusively’. This is a central tenet of agile methodologies. Refactoring is a separate activity to development (new features) or correction (bug fixing). The principal objective of refactoring is to take a piece of existing code and improve it without changing its function.

Core Concepts: Contingency

2022-02-01T00:00:00+00:00

TL;DR Examining the core concept of contingency.

“It depends!”

This is perhaps the simplest yet most important, and arguably most useful, of our core concepts. My go to response is “it depends”, which can admittedly be irritating but is almost universally true.

Regardless of the problem under consideration context will play a significant part in determining a suitable solution. Consequently, any answer is likely to depend upon the context in which the problem presents itself.

Questions of the form, “Which tool is best for X”, “What training/certification is best to pursue for Y”, “Should I use technology Z” can all be answered with “it depends”. Simply put, more information is required before any sensible answer can be provided.

To make matters worse, today’s good answer may be tomorrow’s bad answer. Context changes; new technology becomes available, old technology is no longer supported, new organisational goals are set, new regulations are imposed, different skill pools become available making these skills comparatively inexpensive (making the cost of moving to technology relevant to those skills favourable).

The only inevitability is change and that “it depends” will continue to be an important consideration.

Clarifying the Goals of our CI/CD Pipeline for Video Processing

2021-06-07T00:00:00+01:00

TL;DR In this article we take a step back, clear our heads, and start over focussing on the motivations behind the video processor application.

In the last article I vomited my initial thoughts about a ‘video processing’ pipeline onto your screen. This was a cathartic process (for me) but not a particularly useful one for the project as a whole. In this article we start behaving a little more professionally.

We have a very broad definition of what we want to achieve; given some video sources, some target upload environments, and some details about how to assemble videos and upload details (descriptions, titles, etc.) magically transform the bits and upload them. How can we refine this very nebulous idea into actionable requirements.

If I were working solo and the project were only every to be used by me, I’d most likely start hacking away. Of course, a few weeks from now future me would curse past me as an idiot. The code would be questionable, in all likelihood I’d have only a few (if any) tests, the system would most likely be a freakish Frankenstein’s monster. It most likely would do the job but would be a bitch to change and when things go wrong (and they will) future me will mutter that past me was a crappy coder and should be fired immediately.

Is this because I’m a shitty coder? Maybe. I think I’m a fairly average coder. I try to write clear code but invariably when I ‘just hack out’ a working solution I end up regretting it in the long run.

The following may seem overkill for a one man project but the truth is one man projects that are worthwhile will most likely be used by more people than you guess, and once the project becomes more widely used you’re probably going to regret skipping these early steps. Besides there are always at least two people who use your project; you now and future you. If you now avoids work then future you will suffer.

Figuring our what to make

Before hacking out code it’s probably a good idea to figure our what we want to make. Not in the vague way we did in the last article but in more specific detail, detail sufficient that we could involve others in implementing a solution.

Defining ‘what to make’ is an ongoing process not a step. It is a simple truth that whenever you think you’ve specified everything your system should do, you find something new. This is particularly true as you start implementing the system. In fact anyone who has ever worked on system development will know that the final system seldom implements the initial requirements and only those initial requirements.

This said, we need to start somewhere, so we need some initial requirements to get the ball rolling.

From whence requirements?

Someone must have an itch to scratch. If no one has a problem, or at least a want, then no project would exist. Step one is therefore to identify stakeholders from whom we will extract some initial requirements.

Stakeholders

Much has been written on stakeholders. Here’s my simple method for identifying stakeholders.

Who is going to be pissed off when your system fails their expectations?
What external systems are going to break when your system fails?

We have one clear stakeholder on this project ‘me’ but to make the following process clearer I will wear a number of hats and break ‘me’ into multiple stakeholders according to those hats. Here are my initial thoughts on the stakeholder roles.

sponsor: Typically the person fighting for the project (and funding); the person with a problem to solve, in this case me.
customer: Typically the person paying for the project. Again, in this case, me.
videographer: Films videos.
video editor: Take videographer’s output and cuts it into one or more ‘finished’ videos.
copywriter: Writes ancillary materials (e.g. video titles, descriptions, etc.) intended for publishing with the videos.
publisher: Takes finished videos and ancillary materials and uploads them to target platforms.

Are these all the stakeholders? Probably not. Do you agree with the stakeholders and their descriptions? Probably not. Does this matter? Nope.

As with everything in system development stakeholder identification is iterative and contingent (change depending on current circumstance).

Basic truth

It is easier to criticize than to create.

This notion is exemplified by Cunningham’s Law:

The best way to get the right answer on the internet is not to ask a question; it’s to post the wrong answer.

For our purposes this means the most effective way to solicit opinions it not to ask ‘so, what do you want from the system?’ The best thing to do is say, ‘we’re going to…’ and wait for the opinions on why you’re wrong to flood in.

So, presented with a list of stakeholders you will rapidly be told of all the people you missed (or why stakeholder X is wrong).

The important point at this stage is to identify ‘some’ stakeholders and start the rest of our process. Generally this initial list of stakeholders is obvious. A good starting list will include:

sponsor: The person(s) who fought for the project.
customer: The person(s) who are paying the bills.
users: This one is more tricky. Users are typically the people who interact directly with the system, but sometimes you want to include indirect users who interact with the direct users. For example, the direct user might be the help desk operator, the indirect user might be someone who calls the help desk. The point here being that the needs of the indirect user might influence the direct user’s needs so including the indirect user in conversations may prompt the direct user into an ‘aha, oh yeah we sometimes need that’ moment.

Goals

Hang on, didn’t we say we wanted to identify stakeholders so we could extract some initial requirements? Why is this section title ‘Goals’ and not ‘Requirements’?

Stakeholders are motivated by their goals and the system we are creating will satisfy those goals. Apart from getting stakeholders to identify the problem to be solved this goal process starts to set the boundaries of our system. Goals provide the ‘why’ for our system. If there is not ‘why’ for your system then there is no reason to build it.

Once we have some goals we can start eliciting requirements and relating those requirements to the goals. Any requirement that we cannot trace back to a goal is suspect as it probably isn’t solving any problem stakeholders identified and is therefore either unproductive work or, worse, it will detrimental.

How are goals different from requirements? One of my goals is ‘earn income from online videos’. I can achieve this goal many different ways, I may even be doing this without the new system but the goal expresses a motivation. How might I achieve this goal? One way is to include advertisements in my videos. ‘Insert advertisement into video’ is something I want to do in order to achieve my goal ‘earn income from video’. Goals are ‘why’, requirements are ‘what’.

Hurrah! We have a requirement! Well…No. ‘Insert advertisement into video’ is a capability we want the system to have but not yet a requirement. Capabilities express business impact, the ‘how’ our system will satisfy the ‘why’. Requirements express ‘what’ our system must do to deliver the capability ‘how’, to satisfy the stakeholder’s (‘who’) goals (‘why’). This is the impact mapping concept defined described Gojko Adzik[Adž12].

Anyway, back to goals. Having established our current list of stakeholders our first task is to extract some initial goals (again, as with getting our stakeholder list, these goals are only our ‘current goals list’—they will change over time).

Extracting goals is a bit like being a small child. We constantly ask, ‘Why?’ until we start to get silly answers.

Suppose I offer ‘add adverts to my videos’ as a goal.

‘Why do you want to add adverts?’

‘Advertisers pay for the ads’

‘So you insert adverts to make money? Why?’

‘Income from video adverts allows us to make more videos’

‘Why make more videos?’

‘Making videos generates income and allows me to pay bills and make profits’

Okay, we’re now heading into ‘silly’ territory. Is our goal ‘pay bills and make profits’. Well, yes, with my business owner hat on this is the basic goal, ‘make profit’. What about as a video editor? Creating multiple versions of a final video (one for each target platform) each differing only by the specific advert shown is a pain in the ass so my goal conversation is a bit different with the video editor hat on. Once again, starting with a stated goal, ‘add adverts to videos’.

‘Why do you want to add adverts?’

‘Well, I don’t want to add them, but given the need to add them I want to make the process simple’

‘Why?’

‘Because it’s a fairly mechanical, non-creative part of my job. It’s boring.’

‘So it would be fair to say your goal, for this system, is to offload boring mechanical tasks?’

‘Yeah, free up more creative time by eliminating the mechanical tasks associated with inserting ads.’

Bingo! We have a winner. The video editor’s goal is to ‘free up creative time by eliminating the mechanical tasks associated with inserting tasks’.

Will our system do this? Well, it better, at least in part. The final system may not eliminate all the editor’s mechanical tasks but it should eliminate at least some and it certainly must not add more manual tasks.

Why not continue asking why? ‘Why do you want to free up creative time?’ seems silly to me. The video editors job is adding value to the output using their creative skills. Asking ‘why?’ here will only lead us down the ‘I make money being creative’ line and if you pursue any line of reasoning to the extreme you will end up with one goal ‘make money’, or you pass out the other side into why people exchange their time and skills for money; ‘pay the mortgage’, ‘pay food bills’, etc. and this is obviously not going to help developing the system.

We are seeking the goals relevant to this stakeholder concerning this system.

Is this mechanical ‘why?’ asking approach going to extract all the good goals? Nope. As with everything else these goals are just our starting point. As we proceed we will find some goals are not useful, some goals are actually not the base goal and we need to mine deeper, and we will almost certainly add more goals. Your current list of stakeholder goals provides a scaffold for discovering more detail about the system you are to develop.

Don’t get hung up trying to find all the goals (this is as futile as trying to list all the requirements up front). Get a list of goals sufficient for the next steps and move on, there will be ample opportunity (indeed need) to change this list as the project proceeds. As a general rule, the bigger the project, the more time you will spend identifying the initial stakeholder and goals lists.

If you discover a stakeholder with no goals for this system, they’re not a stakeholder.

You may uncover a goal that reveals additional stakeholders. ‘graphic designer’ is not on my initial list of stakeholders. When I uncovered ‘free up creative time’ in conversation with the video editor this reminded me that there are other creatives involved, one of whom is the graphic designer (they create various elements of the final video but specific to this project they design the title cards to be inserted). A new stakeholder means another round of goal elicitation.

At this point you may be wondering, ‘hang on, given that this process is trying to establish requirements for a system that does not exist yet, how can I ask stakeholders about there goals for this system? You know, the system that does not exist?’ Well, recall that in the first article I came up with a rough idea for a new system? That’s the basis on which I’m building these initial stakeholder and goal lists. We’re saying, ‘if a system like this existed which of your goals would it help solve?’

If your stakeholder mentions one of their goals but it is not relevant to this project, note it down anyway as it may well spin off another project. Similarly you will often hear stakeholders saying, ‘oh, it would be great to have a system that X’ but X is not related to the current project. While it may not be useful at this point to track this back to a goal it is certainly worthwhile making a note of it as it may lead to other projects.

Projects get started for all sorts of reasons but one thing is certain, they never start with a full list of requirements. The project sponsor is typically the person who has a problem to be addressed (the person with the itch) and they must articulate that itch to the people involved in solving the problem (the stakeholders) in such a way that the stakeholders can express their goals for the solution.

Capture

We’re doing good work here. We have some stakeholders and some goals. One of the things we need to do is capture this information. We need to capture it so that we can keep everyone involved (for now the stakeholders and team extracting the goals) up to speed. The format needs to be accessible to everyone involved (it’s pointless to create a document that only your team understands, the document needs to be understood by all stakeholders too).

This common understanding raises an important point; common language. If I say “module” what springs to mind? If you are a programmer you may have several mental models for “module”, if you manufacture spacecraft your mental model(s) will be entirely different. If we are working with an organisation developing software to support designing and building spacecraft we need to be clear on what “module” means in any given context. To do this we start a glossary and share this with all involved in the project so we all have a common reference on the meaning of words.

We now have three things to capture.

Stakeholders
Goals
Glossary

What format should be use? I always favour simple text or text markup because my developer brain sees this as the easiest for me to mangle into different output formats but I am in the minority on most projects and we tend to use other formats such as spreadsheets (MSExcel) or other Microsoft proprietary formats. Bottom line, try to capture all project information in as flexible a format as possible while making it available in formats that all stakeholders find acceptable¹.

Of course we might also keep documentation in a Content Management System (CMS)² of some sort, even a wiki³, with the caveat that we must be cautious about versioning and expectations around control of content. This is a popular choice for technical documentation, less so for other forms of documentation.

That said, this is my project, so we’ll use text files. Specifically we will use LaTeX markup for general documentation (I use it for this website too). These text documents will be processed into various forms for presentation. LaTeX format is generally simple enough for anyone to edit but I acknowledge it can be complex at times and off putting for some (then again few will want to edit documents directly⁴).

Housekeeping

Another thing we will start immediately is capturing these documents in a version control tool. Again, there are many to choose from but I’m going to be a boring conformist and use Git. This is good for you too as you can access the documents at https://gitlab.com/python-utils2/vproc⁵.

Keeping project assets in a version control tool is important but so too is ensuring each document has it’s release version identified. This is something of a rabbit-hole, to avoid overcomplicating this article I will discuss document control elsewhere. For now I will rely on the document’s title and last modified date and time as a unique identity.

References

[Adž12]: Gojko Adžić. Impact Mapping: Making a Big Impact with Software Products and Projects. Ed. by Marjory Bisset. Provoking Thoughts, 2012. isbn: 0955683645.

¹That said, I’ve seen far too many consultant documents produced in PowerPoint. There is a special place reserved in Hell for these people.

²A system for managing content, typically presented online as a web site.

³A form of CMS with a more open editing structure.

⁴In my experience most stakeholders are content to scan documentation in order to pass comment but rarely do they want to edit it directly and even those who insist on an editable format don’t contribute to the actual edit.

⁵Yeah, I know, vproc is a shitty name but this can be changed later.

Core Concepts: Context

2021-06-02T00:00:00+01:00

TL;DR Examining the core concept of context

Context is everything.

Context can change the meaning of a word: ‘Michael Jordan is tall’ vs. ‘The Burj Khalifa is tall’.

Context is vitally important but often overlooked (especially by online ‘experts’ answering questions on Reddit/StackOveflow etc.). Expressing absolute opinion as fact, for example, ‘use GitHub Actions for your CI/CD’. Okay, but this presupposes your workflow is GitHub centred, that you are content to invest in GitHub, lock-in to GitHub, make yourself subject to rule changes and changes to GitHub charging. This is not to say you should not use GitHub Actions, I’m just saying that absolute statements like this should be treated with caution¹ as they seldom consider context.

Examples

Problem Solving

Before starting to solve a problem we need to establish the context in which the problem manifested. What were the circumstances? Was there unusual activity (e.g. more user activity, some unusual process load like a backup restore)? Had a release been recently deployed?

Once we have established the context in which the problem occurred we need the context in which we are to solve the problem. Time frame? Available resources (people, money, etc.). Workflow (can we push a change immediately, can we ‘tinker’ with production systems directly, do we need specific personnel to authorise work).

In real situations a lot of these things, both situation and solution contexts, will be known or at least informally established.

Feature Building

When developing a new feature (even a whole system) contexts similar to those required of problem solving need to be established.

Not only basics such as available resources (time, money, people, etc.) but also existing systems (both IT and business) form the context of the new feature/system.

It is no use developing the worlds greatest accounting package when a simple off-the-shelf package will suffice. Using a SaaS provider may not be an option for secret internal projects.

¹This caution should be increased if the user making the statement attempts to establish expertise using statements like ‘I’ve working in IT for 20 years’. This ‘appeal to authority’ in no way makes the statement right.