...At least three basic ingredients.
If I would have to pick what I think could be three basic ingredients for becoming a successful and valued DevOps, it would be the following.
First and foremost one has to have a passion for automating things. It's the "hate to do things twice" attitude. But this is not software development per se. The goal here is to abstract away a process in a manner that gives us
- the possibility to control, test and run it with a range of options and
- to grant us a meaningful birds-eye view of that same process that will facilitate the discussion of it and of our infrastructure as well as eventually lead to further improvements of it.
It is automation as a way to gain a better overview of the infrastructure, its uses, and the needs for the business
Second ingredient, the "how you achieve automation of a process". Make a real story of your Jira story! Don't shy away nor be lazy to add comments full of details. This is the place where you don't need to worry much about formatting, yet you have all the tools to insert screenshots, links to other boards or documents, link it to further stories, tasks or even epics, explicitly raise the attention to other people that may or not be in your team, add snippets or even full scripts code, etc. Most importantly, it's a single stop shop where you can
- First just jot down an idea of a project
- Draft the requirements and goals
- Annotate some initial tests and investigations for solutions
- Divide the story into tasks and littel milestones
- Go to step 2 and keep improving until a satisfactory solution is found
Again, you get to do all that without worrying about the eye-candy of formatting not even constantly writing full sentences.
Clearly, the story is a living object that may evolve in content as you advance in its solution. And the good news is that it is always there. In the short term this helps gain accountability as well as keep in check our logic. In the mid and long term this attitude serves the traceability of the decisions and solutions taken. Others will certainly benefit greatly from it!
The third and last basic ingredient I would highlight: Show due reverence for the logs. Any scientific field, be it Physics, Math, Engineering or even Language or Humanities can be understood as a composition of processes. A network of maps each with its inputs and outputs: the output of each process is the input of the next.
The logs of your automation include any of its required outputs (say updating a bucket, building a stack, triggering a pipeline, etc.). But it's vital that its output be seen as a story in itself: Reading the logs of your scripts should immediately provide us with a clear view of a
- Full path of your script as it was called
- All values of all variables used
- timestamp of each step and two cents of what it's doing
- which function in the script is doing what at that time
- which function ended in error and in which line of the script
And that should be done with a formatting that is
- consistent
- easy to parse
I can hear some of you already shouting "how does this apply to Terraforming or CD/CI?".
Well, you better structure your Terraform code into modules -yes, beyond the basic main.tf, variables.tf and terraform.tfvars. You see, It isn't then any different! And the whole CD/CI...There is a reason why the mathematicl concept of a map (for CS minded readers, think of lambda calculus, or a language like Lisp or Ocaml) is so powerful: It conveys the most basic idea of a path/process, among a plethora of other technical details. And that's what our pipelines are.
Of course is easy to keep adding ingredients: Eagerness to constantly learn and use new technology, embracing the KISS rule, be quick in documenting things, ... But if I'd have to pick a fourth one I would first go with a
Trust the adage "good is better than perfect".
Although I first heard it as "Perfect is the enemy of good". You get the idea though.
No comments:
Post a Comment