Why developers shouldn’t deploy artifacts

Well, the title is a bit misleading. Developers should be empowered to deploy artifacts, that’s the whole point of the DevOps philosophy; just not from their local environments.

Developer Alice is working on a feature on Module 1 with version 1.0.0-SNAPSHOT. Alice finishes the feature but she hasn’t pushed her changes.

At the same time, Bob is working on a different feature on the same Module 1. He finishes, commits his changes, checks for any incoming changes and finds none. At that point he figures (correctly) that his changes are the latest on the repository, so he pushes them successfully and then does mvn deploy (or whatever the deployment command is).

Now Alice, decides that it’s time to push her changes, but she deploys first (thinking there aren’t any other incoming changes) and runs mvn deploy before updating her workspace. At that point, because the version is a SNAPSHOT, the most recently deployed artifact (containing only Alice’s feature) will overwrite the previous one (containing only Bob’s feature), thus leaving it in an inconsistent state. Any downstream projects depending on this artifact run the risk of becoming unstable.

Now, Alice will probably try to push her changes, but realize that she has to merge them with the incoming ones. Most likely, Alice is a disciplined developer and she will realize that she’ll have to deploy again to make sure the artifact contains both Alice and Bob’s features and it’s consistent with the state of the repository. But this is still a manual, human (and hence error-prone) process.

If we leave the deployment step to a machine (i.e. the CI tool), we can guarantee that there’s only going to be one workspace off of which the artifact will be packaged, making it consistent across the board. It doesn’t have to be anything fancy (although the Gradle release plugin and Maven release plugin are very helpful), just as long as there’s a unique way for artifacts to be created.

One objection to this approach I once heard was: “But why are you trying to make it harder for developers to deploy?”. Well, yeah, it certainly becomes a barrier, but the reason is pretty much the same as why you lock your front door or put a password on your computer. It’s a necessary hurdle to avoid other risks.

Most SCMs today will allow you to add post-commit hooks such that a deployment can be kicked off every time there’s a change, making it even simpler to publish artifacts since it becomes a hands-off process.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: