I was talking to a fellow developer on Facebook (I know, that’s not twitter, wtf!) and he was asking about build and deployment issues – specifically some frustrations around MSBuild. I suggested some things to help with his issues and utilize it better. That kinda got me thinking about how it seems many people don’t know how to use MSBuild in-depth (not that I’m an expert by any means). It seems to be dismissed very early and easily as a build and deployment solution. So, I’m taking the not trodden road, the dusty path, going where no man has gone before…and blogging in favor of MSBuild…in 2011!
(Note: This post isn’t actually how to use MSBuild itself. It’s me talking about why it’s worth taking the time to actually consider/learn it.)
The Case Against
Man, do people hate XML! Nothing more to really say about this – you either hate it or you don’t care. I don’t think anyone (well, human at least) loves XML. At least it’s not EDI, right? However – remember that writing your own MSBuild task can be as simple as inheriting from a base class and overriding Execute(). So if you want to do your whole build/deploy with a .NET language, you can, with a minimal amount of XML.
It’s not sexy
Okay, well, noone has said those words, I don’t think, but that’s what people’s faces say whenever you mention MSBuild. It’s not “the new hotness” by any means and it requires a learning curve. Any other new sexy build technologies have a learning curve too, but for whatever reason, developers (myself included) are much less likely to want to learn something when it’s an old product.
Rob wrote a post saying you should consider it
If I say it, it must already be wrong! I’m totally dooming myself to internet unpopularity! Zomgz! And anyone else who agrees with me even in the slightest will share my dark corner of internet shame. Next I’ll be posting about how awesome VB.NET is, how MSTest is soooo much more awesomer than nUnit, and how WebForms really got the web right! <CharlieTheUnicornsFriends>SHUUUUUUN!!!!</CharlieTheUnicornsFriends>*
*Oh god, I’m using XML even in my blog posts now!
It’s not updated for user friendliness…or I don’t think is…hell I don’t know!
There doesn’t seem to be a real….community around MSBuild. If new updates are happening to it, I’m unaware of them (and I follow several MS blogs..maybe it’s the wrong ones?). Either way, I do not believe it gets updates that would make consumption of it easier, or have more things “baked in”, and some of the other new build tools are more likely to have that user-friendliness and open-source community guiding the directions of their product.
The Case For
*Man, I’m making lots of “notes” in this one! Anyways, none of the “case for” necessarily mean it in a “competing-product-x-cant-do-this” fashion. I’m simply saying that MSTest CAN do these things, and a lot of people seem to think it can’t, or that it’s a big hassle to do these things with MSBuild, which is not the case.
You, and your grandma, already have it installed
“Laziness” isn’t a good criteria for choosing your toolset, but simplicity is. As long as you’re building on a Windows machine, you already have all the tools you need*. You just run it from the command prompt (or better yet, a batch file).
*note that the normal .NET installation does not have web-related targets by default however, which docks 5 internet points from MSBuild. What I’ve done is make a self-extracting exe, that you can call from a custom MSBuild target. You run it once on a given machine, and it’s set from there on out. You could probably do something similar for installing needed software for other builders too though.
You’re already using it
Like it or not, you’re using MSBuild! Until I started writing my own custom targets, I never really groked what was going on in a *.sln or .*proj file. This helped me learn more about how .NET solutions and projects are arranged, how things are coordinated “underneath the hood”. You can always read a book or a blog about these things, but I always find you can’t really understand something until you have to deal with it by hand. Knowing more about what you’re dealing with can a help a lot when you start having issues in your project/solution files, or want to add/edit post/pre build steps.
There’s a nice existing library of community addons
Chances are, if you’re thinking about doing some lower-level task (like, for example, reading XML out of a config, or starting/stopping windows services), there’s probably already a task out there. Granted, other frameworks have this too, and the MSBuild Community Tasks haven’t been updated in forever (remember, it’s old! Time to move on!), but the point is, there is a library out there that’s extremely useful and tackles a whole lot of common cases. The point being – there’s more than what’s just built-in that’s easy to get. A lot of people don’t seem to know this.
Yes, you can do that with it
Whatever “it” is, you can accomplish it with MSBuild. Again, not saying that other frameworks/methods don’t have this either – but MSBuild is extremely powerful. A lot of people seem to equate “XML = Useless”, and I just want people to understand that’s not the case. The fact that you can write your own C# library and have MSBuild run commands in it literally means “can do anything”.
It’s extremely easy to factor-out common targets to reuse them across multiple projects or even multiple solutions. On a previous project we had 3 websites being deployed to 5 machines, all using the exact same target, with no repetition. You can usually factor out things into more targets and chain them or composite them together as needed in higher-level build files. Yet again – not a unique feature, just saying MSBuild supports it, and it’s easy.
What Really Matters
It’s good to remember to come back and focus on what’s important – delivering value. Build and deployment is a very serious part of any project, and unfortunately most of the time it gets cast aside, only to be rushed through at the last minute. Good agile software techniques are teaching us and the industry as a whole to consider these things up front and to make them painless. The fact that we’re even discussing it at all is a great thing! Noone really recommends “deploy from Visual Studio to prod” or “copy these files, then hand-edit that config, the don’t forget to insert these rows in the database…” as a serious technique anymore. What’s even better is that there ARE options out there!
I just hope that after this people keep an open mind about MSBuild, and realize that it’s a powerful solution that can work great on .NET solutions. It’s as “correct” a solution as alternatives such as Albacore, Rake, PowerShell, etc. The only real differences are likely to be your opinion for what fits your style/team/situation better.
So what it boils down to, again, is delivering that value. Pick something that your team is interested in, that your company can easily support and maintain, and that efficiently works with your processes.
I'm going to state something you probably already know
Agile is about the team - not about the products.
It feels like a very obvious truth to me, but I didn't realize it until recently. It was one of those things that as soon as I said it, I realized that it was extremely true. I hadn't heard it before (or it didn't stick - I'm pretty dumb, after all).
Why haven't I heard this before? Why does this even matter? This is probably due to, at least in part, always working on small teams. On the rare occasions where I've been on a larger team (6-7 developers), we had several products. Usually to the point where each developer worked on a product by themselves, or mostly by themselves.
Now I'm going to talk about more things you probably already know!
How things typically seem to go:
Traditional (typically rooted in an attempt to do Waterfall) organization in regards to software development seems to be centered around the products. There's a request for some new software. It gets added to a Product Manager's "list of products I'm PM for". The PM makes a request to the development group. The development group allocates some resources to the effort. This is done by taking one or more developers away from something else they're doing - or worse, they're asked to "split time" between multiple products. Each way has their own major problems.
If a developer is asked to split their time, they now have conflicting priorities. They can ask whoever represents the Product group which product feature is the most important across multiple products, and will get different answers. Everyone will always want whichever product they're closest too (or is the squeakiest wheel) done first. Getting a single clear direction, that doesn't change on a daily (or worse, hourly!) basis will be neigh-impossible.
If a developer is made dedicated on this new product, while at least they won't have conflicting priorities, other issues arise. That developer will likely be working in a silo. No ability to do peer reviews (other than simple adherence to coding standards possibly). Higher stress due to not being able to take sick time. Developing in a black box. Harder to bounce ideas off of peers, since no one else will know the domain. Chances are if someone else has to join in on the product later, that person will be very lost, and will likely end up needing either a lot of time learn the existing codebase, or re-writing the product.
In both cases, any existing products are damaged, as their ability to do planning will be interrupted. If they're attempting to do Scrum, for example, now their velocity will be incorrect, and will have to be recalculated. Again, if things are ran by product, and not by team, and especially if a developer is spread across products, getting any consistency will be extremely difficult, if not impossible.
How organizing around the team fixes things:
When you organize around the team, in a proper Agile environment, one of the first things you'll get is a single Product Owner. Without getting into the full definition of the PO role in Agile terms, the key part that is important in relation to this post is the fact that the PO will set the priority of work for the team. This gives a single person the responsibility of knowing what's important to each product the team supports and the relative priority among the products. This is critical.
The next thing you'll get is predictability. With the developer/QA resources (boy do I hate using that word, but stick with me) being constant, the amount of work the team can get done will be consistent - regardless of the product.
You'll also avoid silos this way. Since a team grooms stories together, everyone will be knowledgeable about the products. This gives people freedom to take time off work as needed, without being "the one guy" that knows how something works. The Company typically likes this aspect when phrased as "If we do this, then if [So-and-so] gets hit by a bus, the product isn't doomed!". If you're practicing some good policies like peer reviews, that will also help spread knowledge about the products throughout the team, as well as let everyone feel that they know all the products on that team.
Avoiding possible pitfalls:
What if it gets to where you have lots of products (typically, several smaller ones and a larger one or two)? Then you have another problem - but it's not solved by organizing around the product. Not that I'd even really want to call that a problem. If one product consumes 80% of the team's time, it may be viable to split the team at that point, so that a larger portion is dedicated to that product, and a smaller team is formed to handle the other products. Be prepared to keep the teams consistent after that point though, and don't start "borrowing" resources from other teams, or you'll end up right where you started.
Splitting the team also means getting another PO - one for each team. It might, in theory, be possible to have a single PO over multiple teams, but more than likely it'll end up with that person not being able to focus on each team as they should.
Many businesses want "on demand" time spent on their product. They want that product right then and there, and later on, interest in that product might slow down (especially once it's been launched, and initial revenue gained). That leads them to want to shuffle development around as needed. Agile is great at providing visibility in the effect these decisions have. By switching the focus from the product to the team, it allows businesses to see how it actually hurts other products, instead of creating the illusion that development is an unlimited resource. It's up to the PO to communicate back to the Powers That Be that the new product can be delivered, but that existing products will have their timelines affected. It's going to happen anyways - but when focusing on the product, there's the false sense that other products are unaffected.
Often the most important thing when selling software (or selling anything, honestly), is managing expectations. By organizing around the team, you will get consistent, predictable results for your clients. Your developers will be able to focus on the work laid out for them, instead of trying to juggle priorities and emails. If you can deliver what you say, your clients will be happier. You'll have happier developers this way too, which lead to less turnover - which will again help with more predictability, feeding back into happy clients.
There are other things I feel are beneficial as well, but this post is long enough! Suffice it to stay, focusing on the team helps solve many problems, and will prevent other issues from arising. Again, this is based on my experience, which is limited to tiny teams, or a larger team with more products than they can handle.