Today we have more tools than ever to build software. In fact, we have more tools today than we have ever had that I would say are required – as a basic minimum toolbox – to develop software. At the start of my career, the toolbox used by the team I was on was minimal – an IDE/compiler, version control system, and some spreadsheets and documents. If we needed something automated, we wrote a batch file. We hijacked an old PC and made it our build server, which when we needed to do a build, we’d log into, get latest from source control, and run a batch file. Deployment? Manually copy files, run some database scripts. The tool landscape is much larger today…but what does a team minimally need? It falls into six different categories, and I’ve described why you need each of these, and some potential options for your team.
(Note: I’m leaving out the obvious like a compiler/IDE)
Configuration management/version control
If you are doing software development, you of course need this. You need this even if you are a solo developer. If you are doing development, and don’t have a version control system, stop what you are doing, go download one (there are free, open source alternatives), and start using it. Why? Because in software development, the most important thing you create is source code, and you need to treat it well. Version it, replicate it, provide a history log. Use a version control system with an “edit/merge/commit” model, meaning that you and multiple other people can work on the same file at the same time.
Options: For the most part, it seems like two are emerging as front runners, especially in the corporate development space: Git, Microsoft’s Team Foundation Server (mostly preferred by MS devs). Interestingly, TFS is now supporting Git, so Git may end up the de facto standard sooner than later. Side note – if you want to learn about Git for TFS, check out Esteban Garcia’s Pluralsight course on that topic. Git has a learning curve.
Next on the list is a tool that can automate your build process. As I mentioned above, the “old school” way of building your software was to do it by hand. This is error-prone, and not repeatable. If your build isn’t automated, you are doing it wrong. Even if you create a script to automate your build, that’s at least better than doing it by hand and risking a mistake, a forgotten step, a corrupt environment, or a typo. Luckily, if you don’t have a build automation system, and need one, your options are plentiful:
For Microsoft devs, TFS/MSBuild is typical go-to build system because it works so well right out of the box. For everyone else, or those with more advanced or cross-platform needs, tools like Jenkins, TeamCity, and CruiseControl are popular options which support lots of different build engines.
If you don’t know exactly what Test-driven Development (TDD) is, or you aren’t sure how to use it, first go buy this book by Kent Beck: http://www.amazon.com/Test-Driven-Development-By-Example/dp/0321146530 Read it, absorb it, believe it, practice it, and make it part of how you write code. It’s critical, whether you are building a huge system or a small one. Small systems sometimes become huge systems, and if you wait to use TDD until after you have a mass of code, you’ll be fighting an uphill battle to use TDD.
The most common TDD frameworks around (at least for C#/Java) are: JUnit, NUnit, MSTest, and xUnit. TDD frameworks exist for many different languages and toolkits, although frankly, some proprietary app dev tools (take BizTalk for example) make it very difficult to practice TDD effectively.
Automated functional testing tools
Let’s face it – manually testing your application is not only boring, it’s a waste of time. Especially when you make some fundamental change, and you need to go back and re-test the entire thing. Or you have to test it on multiple browsers. Or on multiple platforms. Or both. So while we have TDD tools for creating unit tests, those are not targeted at the functionality of your app, and almost never at the user interface. This is where automated functional testing tools come into play.
For web apps, Selenium is a popular choice, and on the Microsoft stack, you have CodedUI tests. If you are a big corporate shop, you might be using HP tools (surprisingly the company that makes your laser jet printer also makes high-end software testing tools). TestComplete from SmartBear is also a compelling tool in this category.
Continuous deployment / continuous delivery tool
I’m classifying this tool as separate from a build automation tool. While a build automation tool may help you implement continuous integration, they often aren’t good at continuous delivery. I see the distinction primarily being that a continuous delivery tool will actually automate the deployment, configuration, and promotion of your application from one deployment pipeline stage to the next. Why is this valuable? Similar to build automation tools, it’s about risk reduction and time management (especially for complex applications).
This is more of an emerging space in the industry, and it’s an interesting one. There are tools like Puppet Enterprise and Chef, and they are highly IT enterprise focused. Tools like AnthillPro and Go are focused on the deployment pipeline scenario, which is what software teams are more likely to need. Team Foundation Server has really lacked this feature for a while, but with Microsoft’s acquisition of InRelease, it now has a product to fill that gap. There are also tools like Deployment Manager from RedGate which have deep database integrations. You’ll want to do some signifiant research before selecting a tool if you don’t already have one. These tools tend to be complicated to install, configure, and use as well – but they are extremely powerful, and will provide massive benefits over the long run.
Finally, in your toolbox, you need some mechanism for tracking what you are building. All the tools above are about how you build it, but we need some sort of tool to know what we are working on.
At a bare minimum – and often one I like to advise teams on – get yourself a stack of index cards, pins, and cork board. Write stories on cards, acceptance criteria on the back, and move them across the board from “To Do”, to “In Progress”, to “Done”. Simple and it works. It’s worked for many teams, and sometimes teams prefer this.
But for more complicated scenarios, there are a huge number of tools to choose from for your toolbox. I’m focused on tools that live in the agile/lean space. Honestly I’m not even sure what tools there are for “waterfall requirements tracking”. I’m sure there are some very pricey “enterprise” tools that have an incredible amount of features you’d never want to use. But with respect to ones that you might want to use…there is Team Foundation Server (whose agile tools are growing organically and quickly), Rally and VersionOne in the “big enterprise” space, and dozens of tools like Pivotal Tracker, TargetProcess, GreenHopper, and many more. There are tons of both commercial, cloud, and open source options to choose from. Do you homework to find the one that works best for you. A key element in finding a tool is one that doesn’t get in they way. It should be intuitive, easy to use, and fit your workflow. You should never find yourself fighting against it.
There are many other tools I could mention as well, such as code review, code analysis, task board tracking, burndown tracking, and load/performance testing tools, I’m setting the categories above as the minimum baseline. In order to do high-quality custom software development in today’s environment, you need to have a tool that fits into each of these categories. Take a look in your toolbox – what’s missing?