Why use Source Control?When you get started with a project, it's really easy to not concern yourself with things like source control. I mean, if you need a backup of your code, you can just copy it into another folder, right? Or maybe rename a file to ".old" whilst you're trying something new. Or if you're making some big changes, how about taking a copy of the whole source code folder to try out your new feature? Or maybe just zip your current source and drop it into a backup folder, stamped with today's date. And what about if your hard drive crashes - simple, just take a regular copy of the code into Skydrive when you need to. Or if you remember to. What if you need to work on a project with a friend, how do you share your changes in a nice way without copying zip files back and forth? Trust me, I've done every single one of these things in the past. All of which work to some degree, but things can rapidly fall to pieces. What if you need to revert some changes, or go back to a specific point in time because that great redesign you planned didn't quite work out? Maybe you need to merge just a couple of the features in your "Test" folder back to your main codebase. Or maybe your harddrive crashes and you have to go back to a backup from a couple of days ago - ah, damn, you forgot to backup last week and just lost 2 weeks of work. What if you needed to find when you made a specific change? That folder of zip files named "ProjectSource_20130426a.zip" doesn't look so good anymore. Using a source control system helps mitigate all of these things. A good source control system lets you keep track and manage all your changes (or revisions) over time. It lets you take copies (or branches) of important milestones and provides tools to migrate code between them. It lets multiple developers collaborate in the same codebase whilst maintaining a definitive version of the code.
Why use an Agile Planning tool?When working on a new game project, it's easy to just roll up your sleeves and wade in, cracking open Visual Studio and starting to code. You know what you're building don't you? Surely you'll just do what you need to in order to build it. Several articles promote the notion of creating an up-front design document, which describes the features of your game and how they'll work together. As a developer you're likely to have a rough idea of how you're going to implement the technical details of the system. You've probably even drawn a diagram on a napkin or in a tool such as Visio. What's missing is a way of breaking up the features of your game into chunks (or User Stories) and the individual steps (or Tasks) that go into implementing them. You also need a way of helping you prioritise the features (and even tasks), especially if you're working towards a deadline - either self-imposed or one set by a third party. If you're working in a team (or even by yourself), it's important to know which tasks have been completed and what's next to do. If working towards a deadline, it's important to know whether you're on track to hit the dates you've committed to or not and adjust your work (or deadline) to fit your current velocity. This is where an Agile Planning Tool comes in. A good tool allows you to do all of these things. It helps you store the User Stories and the Tasks that go into completing them. It lets you assign estimates to the Tasks or Stories to give you a good feel for the amount of work you have to do. A good system also links the code you're developing to the tasks you have to do, so by committing code you can mark tasks as "completed". A good system lets you track your current velocity and trace it against your ideal.
Why use a Continuous Integration system?How many times have you developed software which just refuses to build on another machine other than your main desktop? How do you know if the specific version of the code in your folder even compiles correctly, let alone "works" functionally? In the past I've found myself sat in front of some old code (even a week can be considered "old" sometimes) and not have a clue which bits of the code is functional. This becomes especially important if you're working with a group of developers. How do you know that the change you've just made hasn't just broken someone else's code? How do you measure the quality of your code? How often have you spent hours on a Friday trying to get everyone's myriad of changes for the week all building so that you can show your progress to a publisher or project manager on Monday? A Continuous Integration system helps address these concerns by allowing you to regularly build your software whenever a change occurs and on a set schedule (such as every night). It forces you to automate your build process, so that the chap in the corner with rings around his eyes isn't the only one that knows the magic combination of switches to use for building your project. As part of the build process, you can run your Unit Test suite - perhaps even your deployment process and other environment or integration tests. By continously building and testing your code, you can very quickly discover issues that normally bite you late on. What's more, it gives you the ability to know what your last working build was and have access to the version of the code at any time.
Team Foundation ServiceHopefully by now, I've convinced you that you can reap great rewards from using an Agile Planning tool, Source Control and a Continous Integration system. What's more, if you were able to combine all of these features into a single suite, your life would be almost complete - right? Luckily for you, Microsoft have created Team Foundation Service (or TFS); a cloud-based solution that combines everything we've just talked about.
Features of Team Foundation ServiceYou can see a full list of the features at the Team Foundation Service website. But in brief, we get:
- Source Control in the Cloud - both TFS native and Git are supported
- IDE integration - TFS integrates with Visual Studio, Eclipse and XCode
- Automatic builds in the cloud - build your source on check-in or on a set schedule
- Automate your tests - run your test suites automatically on build; run different suites for different build types
- Manage your work - store your backlog of User Stories and Tasks, view your tasks, associate them with code check in
- Track bugs - log bugs and track their fix progress
- Collaborate - work with others
PricingAll this goodness has to cost the earth, right? Wrong. Right now, a team of up to 5 developers can access all of this for free. Microsoft detail the pricing here. It is worth noting that some of these features are in "preview", which means they are available for no charge, however they may be limited or chargable in the future.
Getting Started with Team Foundation ServiceThe first step to using Team Foundation Service is to hop over to the Account Creation page. If you haven't go a Microsoft Account, you'll need to head over and sign up.
Creating your projectThe next step is to create a new Project. Right now you can have as many as you want. You have to choose whether you want to have Team Foundation Version Control (TFVC) or Git Source Control with your project. It's really up to you. If you're inexperienced with version control, it's easy to get started with TFVC. You also have to choose your project template. Again, it's up to you which you want to follow - popular choices are Microsoft Visual Studio Scrum 2.2 or MSF for Agile Software Development 6.2. The project template dicates the type of work items you see, the states they can be in and how to transition between them. In this example, I'll create a new project called "GDNet Test" using the Microsoft Visual Studio Scrum 2.2 template and TFVC version control system. When you're ready, your project will be created on the system and you're ready to go...
Adding your first User StoryIn this article, we're going to create a "Hello World" application. The first place to start is by creating the user story of the feature we're developing. In this case, it's "Hello World". Add an item to the backlog and fill out the details. Here, you could go to town and add estimates, acceptance criteria and more detail than I've added. What we will do, however, is start adding some tasks. Clicking the New Task button opens up a window for some information. We need to add the following tasks:
- Create the Visual Studio Project
- Create the Unit Test Project
- Set up a continuous Integration build
- Create the Greeting class
- Create the Greeting tests