DevOps answers
29 Nov 2022
Table of Contents
- 1: Area where I took ownership and accountability for a process, information, or something else others relied upon
- 2: Time when I needed to communicate technical information clearly to an audience. How did I develop my presentation?
- 3: Benefits of version control? Branching strategies I’ve used?
- 4: Describe a sample DevOps maturity model.
- 5: My approach for informing, motivating, educating, evangelizing, obtaining buy-in, and guiding
- 6: How does testing fit into CI, and should it always be automated?
- 7: Practical processes and practices to ensure CI/CI pipelines are secure? Where does sensitive info go?
- 8: My experience growing and maturing (and building and stabilizing) automated build pipelines for development teams
- 9: How did changes in organizational / departmental priorities make me adjust quickly? How did it affect me? How did I handle it?
- Any other questions for us?
1: Area where I took ownership and accountability for a process, information, or something else others relied upon
My favorite compliment – I think I’m going to frame this one and put it on the wall – was when I said I didn’t know much about a technology and a colleague replied:
“You are not official – but you’re dangerous enough to help.”
To me, the phrase “It’s not my job” helps set the scene for a great dinner party story about a professional battle scar. But … it’s never something you say instead of doing the work.
In the past few months, I’ve become:
- An accidental technology contract and pricing negotiator for a small Vietnamese restaurant.
- An accidental Javascript debugger, HTML editor, QA test developer, identity and access manager, and DNS specialist for a mass-email software migration.
- The alleged expert about a 3rd-party cloud product I once sent an email reminding someone to test.
2: Time when I needed to communicate technical information clearly to an audience. How did I develop my presentation?
Example
Introduction to XML and JSON for non-programmers
The rough outline is:
- XML and JSON are just sets of rules about punctuation marks to distinguish one piece of text from another inside of a file.
- You’ve probably already worked with another such punctuation standard before called CSV – you may have opened it with an Excel spreadsheet.
- Same idea, but people prefer the XML or JSON standards better when the information they’re gathering is conceptually shaped more like a bulleted to-do list than a spreadsheet.
- They’re not programming languages, but because the punctuation standards are so strict, the information inside of files written according to these standards is often used to control the way a program behaves, so you’ll often run into them in software configuration contexts. (It’s like “I want ice cream” on a “Yes day.”)
- As a non-programmer, developing a comfort with reading and editing documents formatted in the XML or JSON punctuation standards can make you an amazing partner to developers with respect to requirements analysis, troubleshooting, and conducting tests of how easy potential vendor software is to integrate with your existing systems.
How developed
- Ask people for metrics and estimates (meetings)
- Screenshots and illustrations
- Demystifying jargon – all those technical words that save experts time but confuse beginners – see what I did there?
- Metaphor (“Git is spyware”)
- Remind people they have partners in knowledge. No firehose-drink needed.
- Peer reviewers and beta testers – both experts and novices
- Sometimes they become copresenters!
- (“APIs are for everybody” -> “What is an API and why should I care?”)
- Sometimes they become copresenters!
- Volunteers and voluntolds
- Student drives
- Polling the audience
- Next-step suggestions
- Divio’s 4 types of documentation:
- Tutorials (children’s cooking projects)
- How-to guides (recipes)
- Explanation (Wikipedia article on ginger)
- Reference (ponder higher-order ideas at leisure – Salt, Fat, Acid, Heat)
- Whitespace, headings, borders, etc. to separate “asides” from a different documentation-type
3: Benefits of version control? Branching strategies I’ve used?
Benefits
- Comments on the history of a codebase’s evolution.
- Easy-to-read differences between versions of a codebase.
- Easier rollbacks to previous versions of a codebase.
- Easier stitching together of diverse contributions to a shared codebase.
Branching strategies
- Trunk-based (straight to
main
)- My blog.
- Our Git-and-Jenkins misc-shell-script SFTP replacement.
- Works great for 1-hour jobs developing features that rarely have anything to do with each other.
- Feature branches
UST-EASY
Salesforce package.- Should always install and run-all-tests into any old Salesforce environment without issue.
- Creating branches like
common-app-2022-august
off ofmain
and merging them back intomain
with pull requests suffices for giving developers to add features to the package independently of each othe - Works great for 3-week jobs developing features that rarely have anything to do with each other.
- Fork and merge
- Open-source software
- Not a lot of hands-on experience, but it seems to me that it more or less ends up workinga lot like feature branches inside of a single repo, if you do it within a host such as GitHub that provides forking-driven inter-repository “pull request” functionality that resembles in-repository branch merging via PRs.
- Git Flow
- No experience, but I like it as an example.
- My understanding is:
- On day 1, you set up
main
and then branchqa
anddev
. All 3 branches live forever. & No one ever creates branches directly off ofmain
orqa
– only off ofdev
. - Some of these branches off of
dev
are “feature branches” whose contents may or may not ever see the light of day. - Other branches off of
dev
are “release branches” whose contents should not only be merged intodev
, but also intoqa
and intomain
. - Because
qa
andmain
are “write-only” branches, and those writes always have some sort of origin story indev
, theoreticallydev
,qa
, andmain
are quite easy to keep in sync with each other despite their long-running nature. - The long-running nature of branches like
qa
anddev
lets you accompany them with other long-running conveniences that improve quality of life for training and QA documentation, like a promise that their corresponding environment will always live athttps://qa.example.com
orhttps://dev.example.com
, rather than living athttps://a5123-xz.example.com
.
- On day 1, you set up
For everything but the “commit-everything-to-main” model, “squash” and “rebase” skills can help you rewrite history to look more tidy and organized than the way it actually happened – which in the long run is potentially all anyone really wants to see, anyway.
I’m not great at “squash” and “rebase” because I don’t do a lot of work in environments that depend upon sophisticated uses of Git. However, just like I know that I shouldn’t try to fix a faucet without turning off the water supply, I’m highly aware that I shouldn’t commit code to a repository using a sophisticated branching model without being ready to ask for help using the advanced Git techniques that keep them tidy.
And I know enough about Git to set myself up a sample repository and practice what I’ve learned on a bunch of nonsense files before I click the buttons for real in a shared codebase.
4: Describe a sample DevOps maturity model.
5: My approach for informing, motivating, educating, evangelizing, obtaining buy-in, and guiding
I am bursting with desire to share information, but I’m not the motivational-speaker-on-a-billboard type. I engage in persuasion from a customer service perspective:
“What would it take to make this idea work for you?”
- Questions, requirements analysis, drivealongs, notetaking.
- Assurances and follow-through of followup and iterative improvement.
- Overprepare, overresearch, seek training.
- Simplify (e.g. “big run button“), check in whether a rephrase is needed, give & ask for ELI5’s.
- Help others save face and change their minds in public by being the person to “ask stupid questions.”
- Process of elimination. Show people I’m listening to their hesitations by writing down ideas and crossing them out.
I believe that bureaucracies don’t change by fiat.
Of course, there’s legislation and they literally very much do, all the time.
But I think that often somehow only scratches the surface.
At a deeper level, processes in bureaucracies get stuck because people care passionately about excellence. In my experience, bureaucracies form around extreme pride in quality.
People don’t try new things because they’re told to. They try new things because they’re free to.
- If your idea puts their delivery of quality at risk, it’s dead in the water.
- Your idea had better give them quality-delivery superpowers or it’s just make-work.
6: How does testing fit into CI, and should it always be automated?
Should CI testing always be automated?
7: Practical processes and practices to ensure CI/CI pipelines are secure? Where does sensitive info go?
8: My experience growing and maturing (and building and stabilizing) automated build pipelines for development teams
Not a sysadmin, web developer, or department manager.
I’m not a sysadmin, a web developer, or a department manager, so I won’t begin to pretend to take credit for:
- Writing Terraform to provision virtual machines and define their network traffic inbound and outbound rules. (Keith)
- Writing Docker build scripts that generate containers from vendor-delivered codebases. (Sidi)
- Writing Elastic Container Service Terraform scripts that manage Docker container provisioning and autoscaling. (Sidi)
- Writing Terraform to provision permissions and roles. (Julian)
- Deciding whether to build in AWS, Azure, or Oracle Cloud. (May Ko)
Adoption champion
The value that I’ve had the greatest opportunity to add when it comes to growing and maturing build pipelines for departments is knowledge transfer.
I almost went into live, simultaneous French-English interpretation for a living instead of technology. You can take me out of interpretation, but I don’t think you can take the interpreter out of me.
Minimum viable builds and proofs of concept
One of the reasons people drop my name about technologies that aren’t my job is that I’m constantly building minimum viable builds and proofs of concept that imitate my colleagues’ most complex innovations, yet are small enough for me to demo in a lunch-and-learn or an email.
A few recent examples are:
- Replacing our manually-configured Salesforce-to-ERP data synchronization with a fully automated paid cloud service. (I spun up a sample Salesforce, a sample database, and a trial account and validated that the product does what its advertisements imply.)
- Parameterizing database maintenance scripts so that they can pull passwords from AWS Secure Secrets Manager rather than needing constant human interaction.
- Grouping Salesforce configuration settings into loosely-coupled installable feature packages.
- Synchronizing logic-configuration data between Salesforce environments.
- Integrating information about the current state of a Salesforce instance’s configuration settings into a data governance dictionary.
Knowledge Base article examples:
I’m also very talkative and social, and I channel that energy into being one of our IT service management Knowledge Base’s most prolific writers. If you don’t mind, I’m going to read you a few of my titles:
- “ERP web applications, Docker, and you.” Subheadings explore a URL’s journey into existence “down the stack”:
- “As you can see, the website exists on the internet.”
- “ECS runs web servers from ECR.”
- “How we transfer Docker images into ECR.”
- (At this point, long-running server names and Linux filesystem folder names start showing up.)
- “How we obtain our Docker images in the first place.”
- (There are definitely a lot of filepaths and server names at this point.)
- “How we prep a WAR file for Docker Build.”
- “How we prep a configuration or sensitive file for Docker Build.”
- “Providing the Helpdesk with a new campus-wide
TNSNAMES.ORA
file.” - “Providing the Helpdesk with a new campus-wide version of the script-scheduler desktop software.”
- “Controller’s Office middleware service overview.”
- “Testing whether the Controller’s Office middleware server is running.”
- “Testing whether the Controller’s Office middleware server can talk to the ERP.”
- “Restarting the Controller’s Office middleware server.”
- “Troubleshooting the ERP not returning Purchase Order numbers to the Controller’s Office cloud software.”
- “Overwriting a nonproduction ERP environment’s data with fresh data out of production.”
- “IP addresses and ERP integrations to 3rd-party vendors.”
- “How to install WSL (Windows Subsystem for Linux), Ubuntu Linux, and Windows Terminal.”
- “Setting up AWS CodeCommit (Git) in WSL (Windows Subsystem for Linux).”
- “Visually explore Git repositories on your Windows computer with SourceTree.”
- “SSH or SFTP into a Linux server from a Windows machine with key-based authentication.”
- “Making our scheduler run your Oracle PL/SQL script.”
- “Making our scheduler run your Python script.”
- “Template for Oracle PL/SQL script compatible with our scheduler.”
- “Template for Python script compatible with our scheduler.”
- “Testing whether your Windows computer has direct SQL access to locked-down database servers.”
So when it comes to growing, maturing, building, and stabilizing automated build pipelines for development teams, I look forward to opportunities to get more hands-on in Terraform and more big-picture in purchasing.
In the meantime, I’ve prioritized stabilizing the gains we’ve made and broadening adoption by connecting the dots between complex technologies and the actual business needs that they support.
9: How did changes in organizational / departmental priorities make me adjust quickly? How did it affect me? How did I handle it?
I really like firefighting.
I also love documenting, cross-training, and automating so that everybody’s really well-rested when a fire breaks out.
But a bit like with your opening question about taking ownership because something needs to be done – let’s be honest, that’s where the most intellectually stimulating projects are.
This is a small example, but compliance with “FTC Safeguard Rules” is due June 9, 2023 (was Dec 9, 2022).
- “Train security personnel”
- “Limit and monitor who can access customer information”
It impacted me because, correctly or incorrectly, people identified me as the resident expert on 3rd-party platforms that would be involved in achieving these goals.
Until I just Googled FTC Safeguard Rules yesterday, I was under the impression we were dealing with a December deadline for the e-mails I was starting to receive in November.
- Proactively refactored existing synchronizations between our self-guided tutorial learning management system and our ERP so that HR and Infosec could expand current credential-tracking functionality with self-service tools. I was the only person who had worked with our LMS API, and I took myself out of the way as a productivity bottleneck for tracking employee usage of the LMS by building configurable user interfaces on top of the API.
- Took ownership of being mistakenly identified as an “expert” about data available within a 3rd-party vendor’s product and wrote a detailed reply about who else to ask, about which pieces of the puzzle, why, and how best to guide them to giving useful answers.
Any other questions for us?
- What are the most important things you’d like to see someone accomplish in the first 30, 60, 90 days on the job?
-
Performance expectations, goals, and metrics at 1 year?
-
What part of your job are you most excited about over the next few months?
-
What will my closest colleagues get to do once this position is filled that they’re excitedly waiting for?
-
How has your role changed since you’ve been here?
-
What are the team’s biggest strengths and challenges?
-
What’s your favorite office tradition?
-
What are your favorite parts of working on your team?
-
What was your primary reason for deciding to work here?
-
How has remote work enhanced work in the organization? How has the organization overcome challenges with remote work?
-
Time zones / outsourcing? Nights? Weekends? Do you feel all the way on vacation when on vacation? No phone-check during a dance recital or on a long bike ride? Average hours/week? “Spike” hours/week? # of “spike” weeks/year?
-
What does the organization do to promote diversity? What is the DEI strategy?
-
How are projects prioritized and planned? How does that relate to ticketing and customer service?
-
How are design decisions made? And if there are conflicts, how are those conflicts resolved? How does your team approach problems, both technical and project-related?
- What does the team do to stay on the cutting edge of innovation? What are some examples of exciting new pratices and stacks as a result?