Colleague:
I have to prepare for an interview for Monday, and one of the question is if I am familiar with DevOps workflows - I was wondering if you had any resources I can read through regarding that?
Me:
Here is my response RE DevOps.
https://en.wikipedia.org/wiki/DevOps
academics and practitioners have not developed a universal definition for the term "DevOps".
computer science researchers ... suggested defining DevOps as "a set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production, while ensuring high quality".
So given the lack of a consensual definition, DevOps typically means different things to different people so you may need to research your interviewer to make an informed-guess of the DevOps means to them.
But you can make a very strong case that you ARE familiar with DevOps.
- Cite the academic definition of DevOps from wikipedia:
"A set of practices intended to reduce the time between committing a change to a system^a and the change being placed into normal production^b, while ensuring high quality^c".
- Map each of the crucial components of the definition to a step of your own set of practices. Here is how:
-
^a: committing a change to a system. An example of this is when you merge any of your PRs into themainbranch of the tiltPlot package. -
^b: the change being placed into normal production: An example of this is that "^a" automatically triggers a process that builds the website of tiltPlot, and published it to a public platform "GitHub pages" (links below). -
^c: while ensuring high quality: An example of this is that "^a" automatically triggers a process that runs the commandR CMD checkon remote computers (hosted on the GitHub Actions platform) which checks that your software complies with the structure expected by CRAN (the most important repository of R packages), and in turn also runs all of the tests and examples that you wrote to ensure the sofware does what you expect.
Our DevOps practices are supported by multiple tools including R CMD check, devtools::test(), devtools::check(), r-lib/actions (https://github.com/r-lib/), and GitHub Actions (https://github.com/features/actions).
GitHub Actions is the platform that runs our "DevOps" workflows. I typically refer to these workflows as Continuous-Integration/Continous-Delivery workflkows -- or CI/CD workflows for short. These workflows INTEGRATE different parts of our system CONTINOUSLY when we merge commites to main, and at the same time they also DELIVER different artifacts -- such as websites and installation-ready R-packages.
r-lib/actions is a repository maintained by Posit (RStudio). They share the CI/CD workflows that we specifically use in R (https://github.com/r-lib/actions).
Build and deploy a pkgdown website:
- Source: https://github.com/r-lib/actions/tree/v2-branch/examples#build-pkgdown-site
- Copied to our repos with: https://usethis.r-lib.org/reference/use_github_action.html
Run R CMD check:
- Source: https://github.com/r-lib/actions/blob/v2-branch/examples/check-standard.yaml
- Copied to our repos with: https://usethis.r-lib.org/reference/use_github_action.html
There is an ocean of literature but an excellent free resource is "Software engineering at Google". See the chapters on "Continuous integration" and "Continous delivery". They don't mention explicitely DevOps but hopefully you now understand the strong relationship.