DevOps Academy Review Questions (Week One)
A list of questions on DevOps, CD, CI, Version Control, Git and so on. As always, if I’ve made any glaring errors please let me know!
Define the purpose of DevOps as a methodology – explain how it relates to the Agile movement.
DevOps is “finishing off what Agile started”. While Agile methodologies focus on the actual product being made, DevOps expands the Agile methodology into the operation of a organisation itself. Instead of siloing off individuals according to their roles, for example, DevOps enables the mixture and close collaboration of development (making the product) and operations (servicing the infrastructure) roles.
Put simply, DevOps applies Agile development principles and practices to operations — it is “Agile Sys Ops”.
What is Continuous Development? Explain two key advantages and two challenges of using CD.
Continuous Development, also called Continuous Deployment, is a process of developing, building, testing and shipping a product in quick succession. To do this, we use Continuous Integration (CI) and test driven development to iteratively develop software.
This results in earlier return on investment for the business, and an earlier feedback loop — businesses can easily suggest ways the product (and its features) can be improved, and we can even implement parallel (or A/B) testing to see which version of a feature the user prefers.
However, CD does come with challenges and potential pitfalls. Its technical novelty means some developers can be enamoured by the idea of CD, and end up either using the technique when it’s not really required or try to deploy as many times as possible when it’s not needed.
It’s also tricky to set up — even though tools can help with CI and automated testing, time and effort need to be spent getting these tools to play nicely.
Define at least five assets that should be subject to source control.
It’s probably easier to list what shouldn’t be subject to source control: perhaps anything generated by the build should be left out, OS-specific files, backup files and so on. Everything else is fair game and might help documenting processes. Source code, documentation, images and other media assets, make/Gruntfile/Gemfile, tests should definitely be included, but why not burndown charts/task radiators/product backlogs?
Explain what is meant by ‘fail forward’ in Lean and Agile Thinking
What is the difference between CD and CI?
Failure doesn’t have to be fatal — it’s a requirement for success. Real failure is, for example, not launching a product because it isn’t perfect at that moment in time. It’s always better to make mistakes on a small scale, using test driven development and incrementing towards success, so that we don’t lose much time or money.
Though CD and CI are very closely related, the difference is in fact that CD is a software design practice while CI is a tool or solution. CI, in real terms, is a part of CD. CI allows jobs to be created to run a list of activities — if these activites all pass, the CI tool could compile a binary for us.
What is a live-like environment and why would you use one?
A live-like environment is, unsurprisingly, a virtual development environment designed to reflect the production server. Because the environment the developer is testing in is reflecting the production server as closely as possible, the idea is live-like environments reduce friction in pushing hot-fixes and other updates live to production.
You face the challenge of establishing DevOps processes and thinking into an established team and mature product. How would you begin to implement a DevOps culture and achieve behavioural change?
DevOps as an idea is very new, and faces some opposition from businesses (especially considering the idea of DevOps is to unsilo teams and established businesses generally consider silos a productive way of working). We need a more honest, open and corageous team to make DevOps work — to do this, there are some simple steps to take, like keeping offices open-plan and reducing the use of headphones and email to communicate to get people talking!
DevOps and CD in itself can help to achieve behaviour change and build trust — with continuous return on investment, higher-ups can see immediate benefits from teams using DevOps and CD (and in unsiloing teams).
What is meant by version control? Given an example of two version control solutions.
Version control refers to tracking and controlling different versions, or revisions, of some code, document or other information. Every change to the code, for example, is tracked — we can see who changed the file, when, any comments they have left explaining their changes, and sometimes what differences are between the original and their modified code.
Version control systems are divided into centralised —Subversion, for example — and distributed — Git, for example — solutions (and propitiatory and open-sourced software).
Explain the difference between a centralised and distributed VCS.
A centralised version control system (CVCS) maintains a central repository on a server that is shared amongst team members. Modifications each member make are committed to this central repository.
A distributed version control system (DVCS) maintains a master repository that an owner controls. From this master repository, team members clone their own repos and commit their changes to it. Members can then push their changes to the master repository and the owner decides whether to accept the push or not.
In Git what is the difference between untracked, unmodified, modified, and staged resources.
A file is untracked when it is not in the previous commit. Git can see these files, but they won’t be committed if you run git commit. To track files, use the command git add <filename>, or git add . to track all the files in your working directory.
A file is modified when it has changed since the previous commit (and, conversely, a file is unmodified when it has not been edited since the last commit).
A staged resource is one that has been modified and is ready to be committed. There are a couple of ways to stage and then commit resources — either use git add <filename> (or git add .) and then git commit -m “commit message”, or simply git commit -am “commit message”.
Describe the purpose and usage of SSH and how you create a public key.
SSH (Secure SHell) is a way of securing and authenticating communications. It’s a way of identifying trusted remote computers, which does not require a password. A public key is, well, public: it is used to encrypt and decrypt a private key that only you will know, and that is not transmitted with the public key. The theory is that both parties will know each other is genuine, because only the private key can decrypt it. To create a key pair, run ssh-keygen -t rsa. The id_rsa.pub file contains your public key (and id_rsa contains your private one).
What is the purpose of Grunt? Give examples of how it can be used.
Grunt.js is a task-runner. It takes the heavy lifting out of repetitive tasks that developers have to do in order to push their build to the codebase. For example, developers often work with unminified code that needs to be minified before it can be pushed to the codebase. Developers also need to lint their code, concatenate files, or run unit tests. Grunt.js takes care of all of this when the grunt command is run on the CLI.
Outline the major components of a package.json file and how it assists CI.
A package.json file is used by the npm (this stands, in a rather tongue-in-cheek way, for ‘npm is not an acronym’) to easily list metadata relevant to the project. For example, it contains the name, version and a description of a project. A package.json file can contain the dependencies a project requires (say, for example, Grunt.js and any other gruntplugins — an easy way to install these in the package.json file is by running the command npm install grunt --save-dev), and tests to run when the command npm test is run on the CLI.
Explain how Grunt can assist in CI, testing and developer feedback.
We can use Grunt to fire off a Travis CI task when a repository is pushed to GitHub or merged with a master repository. Travis CI tries to build the project and run tests — based on whether these tests pass or fail, a specific notification can be sent to the owner of the repo (for example, via email).
Grunt, as already noted, can also lint/minify/concatenate files and run tests itself when the grunt command is run.
Outline three key difference between relational and NoSQL data solutions.
A relational database uses a structure (also called a schema) to match data. It’s called a relational database because the tables in the database form relations. To query relational databases, we can use languages like SQL (Structured Query Language). NoSQL databases are not relational — it does not require a structure, or tables. This means we can add or remove entire chunks of data without affecting our app. We don’t have to join tables together to get information, because the information may be stored in key-value pairs or in a JSON/XML document, and we can scale NoSQL databases horizontally — we don’t need to add more power to a server to keep up with increasing demand, but spread data across cloud-based servers as necessary.