configuration management

The Joel Test for 2010

Bill Tudor — Mon, 04 Jan 2010 10:52:07 GMT

Back in June, I posted my own version of the Joel Test – updated for 2010. [See Here.]

Do you have a change management system?
Can everyone make a build in one step?
Do your daily builds include automated tests?
Is work item tracking integrated with source control?
Do you fix bugs and write new code?
Do you track progress and manage change?
Do you have a requirements management system?
Do programmers have quiet working conditions and teaming rooms?
Do you use the best tools money can buy?
Are your testers involved in requirements management?
Do new candidates review code during their interview?
Do you do hallway usability testing?

Three’s a Charm?

Bill Tudor — Fri, 02 Oct 2009 10:10:48 GMT

Three’s a Charm

It looks like the third iteration of Team Foundation Server might be a good one. I just finished reading Brian Harry’s post on TFS 2010 and it contains some interesting references.

SourceSafe Replacement?

I never could understand why TFS was often compared to SourceSafe. All the sessions on migrating from VSS to TFS, TFS for VSS users, etc. Is a team really going to migrate from VSS to TFS? Really? You have got to be kidding me! TFS is change management (to borrow a phrase from Rational), and VSS was barely version control.

… but now I think I get it …

All those VSS (or CVS, etc.) users were left stranded – there was no lightweight version control server for individuals (or very small teams). So they all went to SVN. Quick setup, version control, painful (but possible) branching and merging, command line, nice shell client, poor VS client, and all of that.

VSTS 2010

In steps Visual Studio Team System, Team Foundation Server, 2010.

Can run locally on Windows 7 and Windows Vista client OS’
Simple installation / Configuration
Can optional use SQL Server express edition
Can be installed on a domain controller
Stand-alone version includes Work Item Tracking, Version Control

Note that this stand alone version also appears to include the build server/services!

I assume with the new project collections feature, you could move your SQL Express database over to a real SQL Server when your team gets a bit bigger. And good pricing is also on the Redmond minds.

Looks to me like they did their research. And did it well.

Nice.

The Joel Test – Updated for 2010

Bill Tudor — Tue, 16 Jun 2009 09:23:07 GMT

The Joel test is intended to gauge the quality of a software development organization. Ten years later, it is in need of an update. Below is a possible “New Joel Test”, updated for 2010.

1. Do you use source control?

1. Do you have a change management system?

There needs to be a configuration management plan, control of assets beyond “source code”, branching and merging strategy (even if it’s not to branch), release stabilization and deployment plan, security permissions and roles, quality gates for checking and/or merge, etc. Otherwise, “use source control” is just referring to a glorified backup system.

2. Can you make a build in one step?

2. Can everyone make a build in one step?

Individual developers need access to the automated build system. The official nightly build can “build everything”, but developers need to be able to build individual parts, pull together the required assets, and run from a representative staging area – maybe a virtual machine (or two), a network share, or just a folder on disk.

3. Do you make daily builds?

3. Do your daily build include automated tests?

It’s not enough to just build – we need an indication of build quality. “Break the build” should mean more than “does not compile”, it should also mean “does not pass the tests”.

4. Do you have a bug database?

4. Is work item tracking integrated with source control?

What artifacts were changed with a given bug fix? What bug or development task is associated with the most recent change-set? Which bugs are associated with a given merge?

Check-outs (or commits, depending on the source control system in use), must be associated with bug reports or development tasks. Each check-in should reflect changes for one task (unless they are coupled tasks). You should also be able to query, based on a bug report, which artifacts were changed (or ideally, currently in the process of being changed). In other words, change management must be integrated with bug tracking and project task tracking.

5. Do you fix bugs before writing new code?

5. Do you fix bugs and write new code?

A properly run project will have a branching / merging strategy (or tagging/labeling policy) that allows simultaneous bug fixes with new development. A quality organization will be able to correct bugs in previous releases, and ensure those corrections are in the current release. Without copying or duplicating the code base.

6. Do you have an up-to-date schedule?

6. Do you track progress and manage change?

Project tracking must include processes that allow for managing (planning / executing / tracking) change as well as tracking progress and periodic re-planning of the remaining work.

7. Do you have a spec?

7. Do you have a requirements management system?

The “spec” will change; that change needs to be managed. Too often I see organizations with an excellent process for development of the “spec” and a horrible process for managing change in the spec.

Note: In 2010, if you don’t have a “spec”, you automatically get a ZERO on the new Joel Test and there is no point in continuing on.

8. Do programmers have quiet working conditions?

8. Do programmers have quiet working conditions and teaming rooms?

The teaming rooms are more than a room with a white-board. There is a conference phone, computers (more than one), projector, and lots of white boards. Code reviews, code walk-through, mentoring, design, dispute resolution, meeting with customers – can all take place here.

9. Do you use the best tools money can buy?

No change needed. This one is timeless.

10. Do you have testers?

10. Are your testers involved in requirements management?

The test team needs to be involved in the requirements management system as well as the product validation process. Tests are executed against the requirements. The testers should have authority to approve/reject a deployment as well as approve or reject a requirement. Otherwise, they’re just testers.

11. Do new candidates write code during their interview?

11. Do new candidates review code during their interview?

“Writing code” is one thing – understanding code is another. Candidates should be able to answer questions like “is this code thread-safe?”, “is the code well-commented?”, or “Is the implementation appropriate” – and why. Printing fizz-buzz is one thing; being able to appropriately critique a page of code is another. As a bonus, you could always ask them to re-write it and get the best of both.

12. Do you do hallway usability testing?

Huh? I’ll have to go and read the original on this one, again. I will leave it alone here.

* * * * *

The Joel Test updated for the year 2010. And a few more months to get it right.

Setting up Subversion 1.6 Server

Bill Tudor — Mon, 13 Apr 2009 03:47:26 GMT

Subversion 1.6 was release a few weeks back, and I am finally getting around to installing on a server here. I plan to create a new repository with this install, importing older projects in as required. I will be installing into a virtual machine instance, since they are easier to manage and move around.

Downloads

I downloaded the (free) subversion components from Tigris.org:

Windows Binaries (as a simple ZIP file)
TortoiseSVN as an MSI installer
ankhSVN as an MSI installer

These files were placed (staged) in a shared folder on the server so that I can easily install on various clients around the network. The “Windows Binaries” download contains both the server side and the client side command-line tools. TortoiseSVN is a client-side Windows shell extension (I downloaded both the 32-bit and 64-bit versions). ankhSVN (I always forget what that stands for – the name should be changed if you ask me) is a Visual Studio integration package for vs2008. Note that this component, at version 2.1, is not yet in final release form – I had to download the latest daily build to get subversion 1.6 support.

Server Install

There is no “installer” for the server install. Yes, I know there are people out there with “server packages” to download – some are even free - but it is just as easy to do it all yourself. Here are the steps I took:

Created a folder named “Tigris Subversion” under the Program Files folder
Changed permissions to: Administrators:Full, [ServiceAccount]:Full, Users:Read
Copied in the folder “svn-win32-1.6.0”, which is just the un-zipped distro package

Note: I plan to use a special [ServiceAccount] user to run the subversion server service so that user can be setup with proper security rights. By this I mean the user can read/write the subversion repository, log on as a service on the server machine, and very little else (no rights anywhere else on the network).
Create/register a service with the Service Control Manager (SCM) using the command:
sc create svnserver binPath= "C:\Program Files\Tigris Subversion\svn-win32-1.6.0\bin\svnserve.exe"
Use “regedt32” to modify the service entry to include --service -r "C:\Program Files\Tigris Subversion\repository" on the command line, Tcpip as a “depends on” service, and startup set to Auto (last two items not critical).

Note: Step 5 can be done along with step 4 assuming you know how to use the “sc.exe” command properly. I can never figure it out, particularly when there are spaces in the pathnames, so editing the service entry in the registry is easier for me.

Create Repository

Run the command: svnadmin create "C:\Program Files\Tigris Subversion\repository"
Edit the file “svnserve.conf” in the repository folder; turn on username/password.
Edit the file “passwd” in the repository folder; add some users and passwords.

This creates an empty repository in a folder named “repository” in my installation area. For added security, I then removed the Users:R permission completely from this folder. Only administrators and the special TFSService account can access the repository, which includes the source code as well as the password and configuration information.

Final Steps – Running the service

Punch a hole in the firewall for Tcp port 3690. I set the scope of the firewall inbound rule to “local subnet” since I do not plan to come in over the internet. If I did plan internet access, I would probably run subversion server under Apache and come in using port 80. I do not know how to do this, as I have never attempted to do so. The “SVN” protocol over port 3690 is perfect for a little LAN. (and super-fast, too).
Start the service using “net start svnserver” (or whatever you called the service), or using the Services MMC snap-in.

If all goes well, you will have an SVN server running as a service on port 3690. Check the task manager. View ports on “netstat –a ”. The subversion server process is pretty light-weight, clocking in with a mere 3Mb working set.

You can run more than one server (on different Tcp ports), to serve up more than one repository.

Testing the Install

A quick test: run the command svn info svn://localhost on the server. The response let’s you know everything is working. Well, almost everything. We can’t test the firewall settings until we move over to a client. In any case, we can log off the server now. Time for client installs.

Client Install

I recommend using both the free Explorer shell extension (Tortoise SVN) and the free Visual Studio integration package (ankhSVN).

Run the MSI installer for Tortoise SVN
Run the MSI installer for ankhSVN

Once installed, I like to change the Tortoise SVN settings to perform “Icon Overlays” only on my planned SVN workspace folder. To do this, choose settings from the Tortoise SVN context menu, available with a right-mouse on virtually any file or folder in Windows Explorer, and set the exclude path to “*” and include paths appropriately under the “Icon overlay” section. I don’t normally change anything else. The SVN icons are a bit cheesy, if you ask me. Must be the lack of open source designers.

As for Visual Studio, the Subversion add-on functions just fine along side Team Explorer (TFS Client). You just have to remember to change your current Source Control Plugin in Tools|Options from time-to-time when working with different projects that are controlled under the different systems. I have not run into any issues.

To access your subversion server, just use the URL “svn://servername” and the username/password you setup earlier. Both clients cache this information locally, so you typically only have to enter it once.

Final Thoughts

Overall, not too difficult. Of course, you don’t really need a separate server machine – you can run svnserv.exe right on the client machine, and store the repository on local disks, removable disks, or a network share. I like using a server, however, so that I can primarily work on my desktop machine but can quickly checkout a source tree on the laptop, go on the road, and sync up all the changes with a commit when I get back home. [This process works equally well with Team Foundation Server’s new “work offline” feature introduced in vs2008].

There’s a lot to like about subversion, particularly if you only need source control. It’s perfect for my setup, here.

One gripe I have with Subversion on Windows is that it does not (to my knowledge) integrate with Active Directory, therefore you have to maintain an “alternate” username/plain text password file system. There may be other ways to handle this, but I am not aware.

My Approach:

Lock down the passwd file, allowing only [ServiceAccount] and administrators access.
Create users
Use reasonably strong passwords
Never use Windows account passwords

Subversion clients cache login information so lack of integration with Windows Authentication is really not much of a big deal after all.