Originally published on Developer.com, December 9, 2016.
Bridging the gap between development and the infrastructure teams is the deployment specialist. These days the job is often titled DevOps specialist indicating how these two worlds are being merged. You can see how this role started in Anatomy of a Software Development Role: Deployment.
Q1: What check-in standards do you recommend before a build can be scheduled?
A: The goal here is to get the candidate to articulate what source control conditions should be met before a full build. For instance, there may be a requirement that third party analysis tools be run before a build can be performed or scheduled. A candidate may also suggest that, in some cases, before code can be checked in for a build, it might need a code review.
Q2: When should builds be scheduled, and when should the builds be “on-demand”?
A: A candidate should recognize that scheduled builds work well when there are a large number of developers on the team that may cause overlapping builds to happen (or to need to be prevented). On-demand builds are appropriate for projects with fewer developers, and when it makes sense for developers to iterate on each other’s work several times a day.
Q3: How do you refresh data into the quality assurance environment?
A: A candidate’s answer should include how production data is moved to the QA environment on a schedule. They should mention how the data is partitioned, so only some of the data comes back to the QA environment, and how the data is anonymized where that is required.
Q4: How do you prevent accidental connections between environments?
A: Environments should have barriers preventing them from talking to one another, so that the production system doesn’t use services from the developer workstations or the integration environments.
Q5: How do you push configuration changes through environments?
A: Configuration is tricky to manage since the developer adds new configuration options to the software, and each environment has its own configuration files. A candidate should discuss that, typically, there is a merge process to create final configuration files out of parts which are solution-specific as well as some which are environment-specific.
Q6: How do you package your deployments?
A: The answer can be MSI, ZIP, or any mechanism. The intent of the question is to identify the packaging mechanisms that the candidate is familiar with and has used.
Q7: How do you perform “smoke tests”?
A: Smoke tests are designed to quickly indicate a successful or failed deployment. The answer here should include automated or semi-automated execution of smoke tests, and a candidate should identify the kinds of tests that should be used to quickly assess whether the deployment was successful or not.
Q8: How do you manage roll-backs?
A: A typically overlooked process is what happens when the build fails to deploy to an environment. Understanding the steps that are taken — and that there are ways to recover – is the key to this question.
Q9: How do you know when to deprovision dynamic test environments?
A: Generally, test environments are deprovisioned because there are a maximum number of environments that can be active at any one time — or because a time limit has expired. Conditions may dictate that users are notified before an environment is recycled.
Q10: How do you secure certificates and signing information?
A: Because builds should be signed — and impossible to produce a version of the software not created on the build server – keeping the certificates and private keys restricted is important. However, developers need to be able to build the software for their testing. The response should discuss how a candidate can build for themselves while only the build server creates official builds.