very environment has them: The dreaded manual tasks that drain productivity from the team and add instability to the processes. We usually dedicate only half our brain power?and never enough time?to deal with them, which only compounds the problem. But what if you could automate the most painful tasks and gain a huge boost in productivity and speed of delivery?
Anyone who has worked on a large project, especially one with multiple developers, knows the pain of dealing with code change conflicts, the “works on my machine!” syndrome, “magic” builds, and other process and procedure anti-patterns. Developers hate having to deal with these things, nonetheless, we always get stuck having to do them. In this article, I’ll walk you step-by-step through some simple changes you can make to your environment to eliminate many of the non-code related headaches. By producing reliable, quality builds every time and easing the pain of deployment to multiple environments you’ll be able to get back to doing what you really love: Coding!
|Author’s Note: All the tools used in this article are free and most are open source. You can try out these techniques with no startup cost other than your time. All the tools have active communities with mailing lists, wikis, and websites from which you can learn more, ask questions, and even contribute. If you find any of these tools useful, please consider donating some time and contributing some documentation, FAQ answers, or tutorials back to the community to help make the tools even better!|
Keep Your Tools Sharp
Raise your hand if you love preparing a release build for production development or release-to-customer. If you didn’t raise your hand, you’re like most people involved in software projects. Sure, you know that there are many new and old tools that help you automate these things, but it takes time to get up to speed on them and use them correctly. It’s an old problem. Stephen Covey’s book The Seven Habits of Highly Effective People uses a really great tree-chopping analogy for this concept: “I don’t have time to sharpen the saw, I’m busy sawing!” If you don’t take the time to sharpen your saw, eventually the growing inefficiency of dull tools and over-work will choke your productivity. Time invested in keeping your tools sharp can pay back handsomely.
Remove Friction and Surprises
Repeatability is a virtue. It’s both something you strive for and a goal to be achieved. You should try to identify friction/pain points and try to automate them as soon as possible. One fact I have observed in my projects is that automating a frequently-repeated task is always worthwhile. The time it takes to automate a task is usually recaptured after the third or fourth time the task is repeated. So the ROI happens extremely quickly. The key to automating these tasks, however, is to have the right tools and know how to use them.
In summary, you should strive to eliminate all the “magic” in your software process. If you can perform a task on one developer’s box, you should be able to do it on any developer’s box. You should be able to eliminate all surprises as quickly as possible, and automate all manual tasks in the critical path so you can mitigate risk to the maximum extent possible.
Key Aspects of Repeatability
This article covers five key aspects of a repeatable environment:
- Source control
- Automated build
- Automated testing
- Automated deployment
- Continuous integration
|Author’s Note: Previous issues of CoDe Magazine have covered many of these topics, and you’ll find links to those articles here, so that you can delve deeper into that particular subject.|
|Editor’s Note: This article was first published in the November/December 2009 issue of CoDe Magazine, and is reprinted here by permission.|
Takeaway: Code should have its primary home in a central, well-known location. The point of source control is to eliminate the guesswork of who has the most recent source code files. This is especially crucial on a project involving multiple developers, as the situation can quickly get out of hand. Eliminate the waste involved in having to manually “diff” files or look at last-modified dates to try to figure out which version of a given source code file is the correct one. Eventually, you’ll move on to other projects and someone else will have to maintain this code. Will they be able to find it and feel confident that they have the code that matches what’s actually deployed? Source control helps address all these problems.
Several good offerings are on the market today for source control management, including both free/open-source and commercial offerings. Several of the more common/popular ones include: Microsoft Visual SourceSafe, Visual Studio Team System Team Foundation Server, and Subversion (open source). Personally, I like Subversion, so this article uses a Subversion example for instituting source control.
A Quick Introduction to Subversion
Rick Strahl covered Subversion in his July/August 2008 CoDe Magazine article. If you’re coming from a Visual SourceSafe background, you’ll find Subversion’s mode of operation is a little different. SourceSafe uses a library approach (i.e., “lock, edit, unlock”) mode. Subversion uses a collaborative approach (i.e., “copy, edit, merge”). Using Subversion, you simply retrieve the latest working copy from the server and then just start working on that local copy. When ready, you commit your changes to the repository. Subversion will merge your changes with other people’s changes. If Subversion encounters any trouble, it will ask for your help. In my experience, this is rare, but when it does happen, there are powerful tools such as the TortoiseSVN GUI client (more on that later) that can help you deal with merge conflicts easily. Compared to the alternative (having to shout across the cube farm to tell Frank to unlock a file you need), merge conflicts are a small price to pay for all the other functionality in Subversion.
Setting Up a Subversion Server and Repository
The fastest way to get a Subversion repository up and running is to download the free VisualSVN Server product from the folks that also make the VisualSVN product (a commercial Visual Studio add-in for Subversion interaction).
Install VisualSVN Server on a server or other computer that will be highly available. Don’t install the Subversion repository on your developer workstation, because it will hammer disk performance when clients are performing operations?not to mention the problems created if you have to reboot or shut down. You should also set up backups of your SVN repository. This can be as simple as zipping up the repository folder and copying it to another computer or doing a proper backup according to your company’s IT backup policy.
After setting Subversion up, you can add users. I wouldn’t get too bogged down in configuring their access permissions at this point. That can come later when you’re more familiar with the system and your usage patterns.
Installing VisualSVN Server
After downloading the VisualSVN setup package (MSI), run the installer and accept the license agreement. You’ll need to enter some important settings (see Figure 1), including the root path for your repositories, the HTTP/HTTPS port number, and the type of authentication you wish to use.
|Figure 1. Visual SVN Server Options: After you run the installer, you’ll see the installer options screen, which requests some settings.|
- Location: This is the location to which the VisualSVN server itself will be installed. I recommend leaving this as the default.
- Repositories: This is the folder into which all your repositories will go (you can have many). I recommend putting this on a separate drive if you have one depending on your performance needs and number of developers using the server.
- Server Port and SSL: Change this if you need to avoid port number conflicts. I recommend leaving this default and using a secure connection. VisualSVN will generate an SSL certificate for you to use internally so you don’t have to purchase a full SSL certificate for public use if you don’t need to.
- Authentication: VisualSVN Server and Subversion can maintain their own user database, complete with hashed passwords. This is probably the easiest/simplest thing to do to get going quickly. If your organization requires Windows authentication (or you prefer it), use that option instead.
After installing the server, open the VisualSVN server manager (see Figure 2) to configure your repositories, user security, and other options (no config-file-munging required, unless you really want to).
To create your first repository, right-click on the “Repositories” element in the tree view, and choose the “Create New Repository” option. For the purposes of this article, I called mine MyFirstRepository. Note that as you type the repository name in the text box, the URL of your repository appears below (see Figure 3). Before you click OK, you may want to jot this down or copy it to the clipboard for use in a little bit. Next, add users and groups as appropriate. For now, it may be easier to just create a single user that has access to your new repository. While you’re here, you may want to create a user called “TeamCityUser” for use later if you configure a Continuous Integration server. Beyond that, you can get fancier with user accounts later. For now, let’s proceed with the basic setup.
Now that you have a server set up as well as a new repository and associated URL, you can connect a client and start adding code!
Setting Up the Subversion Clients
On your developer workstations, I recommend installing the TortoiseSVN Subversion client for Windows. It integrates with Windows Explorer and works really well. If you prefer a source control workflow integrated into your Visual Studio IDE, you can use the free, open source AnkhSVN or the commercial VisualSVN.
To keep things simple for this article, I’ll use TortoiseSVN as the client, but I strongly recommend you check out Ankh and VisualSVN when you get a chance.
First, on your developer workstation, download and install TortoiseSVN from the link above. Next, decide where on your file system you want the code to reside. Let’s say you chose C:Code. In Windows Explorer, create a sub-folder called