Day 1

You walk into your new job, day 1. You start poking around and realize that there’s a reason why they hired you (or at least why they hired a release engineer at all). Some solutions are over-engineered while some others are just patches, people ask you what exactly do you mean by “deploying” and you look around for the CI dashboard but you find none. At this point you’re probably either very overwhelmed or very excited.

In any case, you will have to start somewhere, but the question is where? The less than ideal branching strategy? The lack of understanding of what a SNAPSHOT is? The absence of Jenkins, Bamboo, TeamCity or whatever your CI of choice is?

The dichotomy always seems to be: grab the low-hanging fruit or tackle the biggest pain? Get a quick win or plan for long-term dividends? Assuming you have a certain degree of freedom, the best choice is probably getting something done as fast as possible and establish yourself as the authority in this area. Because that’s what you are (remember questioning why they hired you?)

This is the first post of (hopefully) many in which I will try to document my achievements, frustrations and pet peeves in this world of release engineering. Hopefully, they start valuable conversations and also help connect people interested in Release Engineering.

Anyway, I wanted to actually document something, so here’s a couple of lists of things that you may relate to. I will expand on some of this points in future posts.

Pet peeves:

  • Call it a build instead of a release, a deployment or a push. Well, actually the pet peeve is not about calling it a build. It’s the fact that it’s actually a build. That is, the source is compiled and/or packaged every time it is pushed to a different environment.
  • Along the same lines of the previous point: calling things other than what they are. Mercurial manages repositories, Maven deals with projects and modules, Jenkins executes build plans. It makes for much clearer conversations.
  • Packages versioned 1.0.0-SNAPSHOT forever. This either indicates a lack of understanding of what a SNAPSHOT is or the fact that you wanted to put a version on something that doesn’t really need one.

Frustrations:

  • No tests. I think we’ve all been there. You search src/test only to realize that there are no tests. No JUnit, no Jasmine, no Selenium. Nothing. You think: “Oh, maybe they’re in a different source control module”; nope. “How are you assessing the quality of the application?, “Well, QA executes the tests manually“. Oh boy.
  • Writing scripts to automate things. Ok, this is not really a bad thing. Unless the reason for automating is just to save time on something that’s a pain to do every time. Well, guess what? What you’re really doing is just automating pain. This strategy usually just masks issues that have to be addressed with a sustainable solution rather than just a temporary patch.
  • Versioning a web application. Version numbers are useful for many other things, but not for an application over which users don’t have control. When was the last time you decided to upgrade Facebook to the latest version? Throw that version number out the window, you’re never going to need it for backwards compatibility, or for troubleshooting purposes, because those versions will never exist again.

Wins:

  • Setting up a CI server is easy. You can get pretty much any tool to check out and compile all the source control modules developers use. Even if there are no tests to execute, at least you make sure that developers get something that compiles and they can work on.
  • Lock down the artifact repository. Don’t let developers deploy from their machines. Their local workspaces are usually considerably different from each other and this causes inconsistencies in the artifacts produced, specially if dealing with SNAPSHOTs. Have the CI server (perhaps the one set up in the previous point) be the only entity that can deploy artifacts. Not even you can.
Advertisements

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s

%d bloggers like this: