Tuesday 21 December 2010

Team Foundation Server 2010 (1)

I have been working as part of a team of six developers for just over a year now. This has been the first time in my career that I have been part of such a team and in that time we have created a lot of components. These are scattered across a range of applications - web apps, web services, databases, SSIS packages and standalone .exe files that we run from servers on a schedule.

We're at the stage now where controlling change amongst the team is difficult. We are using Visual Source Safe as our source code repository and it's not brilliant. I'm never 100% confident that when I try and build a new version of the application that I'm working on and publish it to our test environment that it will have all the most up to date code in it. So instead of moving forward with functionality I'm spending time bug fixing changes so that I can get a demo working for customers.

I'm also finding the whole build process very unsatisfactory. At the moment I have a Visual Studio 2008 solution with a dev project that we're all contributing to and a test project that contains just the files I need to run a particular app. Creating a build involves knowing which of the files have changed, copying them into the test project, remembering to change the namespaces and then publishing to the test server. It's a slow and irritating process.

I also have the attitude of team members to deal with. Communicating with people when you all sit in a space that's about 10m square should be simple but it's not. I'm not getting told when things change and only find out about changes when I try and publish a version of the app and it stops working because a datatype has changed in the database.

All this is stopping us progressing. Fortunately we have just acquired some MSDN developer licenses that allow us to install Visual Studio Pro 2010 and Team Foundation Server. I have been reading plenty of stuff on the web about how these development tools will help to resolve the problems that I'm facing and move the team forward. So I'm going to spend the next few months concentrating on developing the practices and procedures necessary to improve our efficiency and quality. I would also like to explore the opportunities that Agile programming will bring to the team and see how well it fits with what we do because I think we can learn from that too. The next set of blog posts will all record my findings as I carry out this piece of work.

No comments: