ing providing gourmet lunches to em-
ployees at no charge. We can all agree it
is not a prerequisite for DevOps.
Secondly, I’m not sure if someone can
“do DevOps.” You can use DevOps techniques, methods, and so on. That said,
people use that phrase often enough
that I think I have lost that battle.
My friend and I discussed his situation further, and soon he realized that
DevOps would not be impossible; it
would simply be a difficult transition.
Once the transition was complete, however, life would actually be much easier.
My friend had one more concern.
“Look,” he confessed, “these deploy-
ments are risky. Every time we do one I
risk the company’s data and, to be hon-
est, my job. I just don’t want to do them.
Doing them every few months is stress-
ful enough. Doing them more frequent-
ly? No, sir, that’s just irresponsible.”
As I discussed in a previous ar-
ticle (“The Small Batches Principle,”
Communications, July 2016), when
something is risky there is a natu-
ral inclination to seek to do it less.
Counterintuitively, this actually in-
creases risk. The next time you do
the risky thing, you will be even more
out of practice, and the accumulated
changes to the surrounding environ-
ment become larger and larger, mak-
nearly guaranteed. Instead, DevOps
takes the radical stance that risky
things should be done more frequent-
ly. The higher frequency exposes the
minor (and major) issues that have
been swept under the rug because
“this happens only once a year.” It
forces us to automate the process,
automate the testing of the process,
and make the process so smooth that
risk is reduced. It gives the people in-
volved more practice. Practice makes
perfect. Rather than running away
from what we fear, it bravely takes
risk head on and overcomes it. Like
anyone who has experienced post-op
recovery, you repeat the exercise until
it is no longer painful.
There is always some fixed cost to
deploy. You should always, in princi-
ple, be driving down the fixed cost of
deployment toward zero. Increasing
deployment frequency without driving
down that fixed cost is detrimental to
the business and irresponsible.
The rest of this article describes two
practices that enable rapid releases in
an environment that uses SQL. Implementing them requires developers,
quality assurance, and operations to
get out of their silos and collaborate,
which is unheard of in some organizations but is the essence of DevOps. The
result will be a much smoother, less
painful, and certainly less stressful
way of conducting business.
Technique 1: Automated
In the old methodology, any schema
change requires the entire application to be shut down while a team of
experts (or one very overworked DBA)
modifies the schema manually. If you
are going to do fully automated deployments, you need to have fully automated schema updates.
To that end, the application should
manage the schema. Each version of the
schema should be numbered. An ap-