On confusing Build and Deploy
• Julian Simpson
We've been having a conversation at work about the different goals of build and deploy. I thought I'd share some of my response to a question "does it matter if you mix up build and deploy? Why don't we use build tools like Ant to deploy with?":
To me, build is the place where you compile and test your code, package code and other artifacts up for later deployment. "build" is a broad and overloaded term; we spend much more time testing than we do building. I've also seen people use the term build as a superset of everything build and deploy.
So "deploy" is taking the artifacts that we made and then actually making them run on a production server(or similar).
I guess because deploy is often a subset of build (you need to deploy an application to a container to test it for example), it's easy to think of it being the same. But deployment should be incredibly simple, as production deployments can be tense affairs. It's my belief that you should be rehearsing your production deployments hundreds or thousands of times by making the CI server exercise the process. Once you have:
- a simple repeatable deployment process
- tests to make the CI build fail if dependencies aren't met (e.g. if the deployment scripts aren't valid),
- and it's run a lot,
then you remove a lot of risk and tension at deployment time.
So I guess my answer is that there shouldn't be much need for a complicated deployment process. You might argue that we might still use a build tool on the production system, and only use some small percentage of the features. But you haven't met the systems administrators yet.
The systems administrators have (or should have) incentives to keep systems secure and stable. They won't like having build tools on the box because (especially if they are Unix sysadmins):
- they probably have other tools (like, most of the Unix userland)
- it's long been considered a security hole to leave that stuff lying around production
- it might be perceived as the thin end of the wedge with respect to circumventing the release process ("No problem. We'll rebuild the code with that fix on the master server")
The key is to find a happy medium between making your code easily deployable without compromising the release process. For all stakeholders. I appreciate that some of this may not hold true for .NET projects. Sorry.