Information Technology Reference
In-Depth Information
The Magic Machine
Many developers have had this machine at one point or another. The situation
occurs when you have written and thoroughly tested your software, but when it
is deployed on another machine (like one of the testing machines), something
doesn't work. There are many possible reasons: Perhaps you forgot to commit
a file to the version control repository, maybe the testing machine's configura-
tion is different, or an application server's pooling mechanism is set for fewer
connections. But in all cases, it means that something is
different
between your
machine and the other machine(s). This is when you exclaim, “But it works on
my machine!” because you can't even get it to fail there. Could it be a “magic”
machine?
“Magic machines are those one-of-a-kind magical pieces of hardware that
happen to be the only machines capable of building a company's software
application. This scenario isn't as far-fetched as it may seem. I've run across
these wizardly beasts a number of times in my career. These machines turn
demonic, though, when dependencies are lost or when the inevitable bit rot
strikes. It's easy to see how a normal machine in a company's infrastructure
can turn enchanted: over time, developers inadvertently added hard dependen-
cies into the machine's script, made references to fully qualified directory paths,
or even installed tools that only exist on a select machine, which slowly pre-
vented the build from being able to run on any other machine.”
6
Magic machines occur because of the “hard-wired” dependencies to the
machine on which you are building. This can also occur on the integration build
machine. Sometimes people will add an environment variable or apply a config-
uration change to the build machine to solve a problem, but forget to script it so
that it can be used on another machine. If your build machine were to fail to
work, what would be the impact? How long would it take you to get up and run-
ning again?
There can be many solutions to this problem. You can script most depen-
dencies into your build and include the dependency in your repository. Another
option is to create an image of certain dependencies, such as your database or
application server. Furthermore, you can refactor your build scripts to remove
many of the hard-coded dependencies (for instance, environment variables)
and make a relative reference instead.
6
