Building Software as a Team in TFS (with Sitefinity)
There are (generally) three types of software development:
- Individual – it’s just you and your genius code
- Small Team – You see them. They see you.
- Big/Multi Team – You didn’t even realize your project had code that did that
The need for source control for each of these groups is present, but the motivations are very different. Individual developers often use source control as a simple way to remember what files they’re changing between releases and to have an insurance policy against local system failures or changes that require a rollback.
As soon as you are more than one person, though, source control becomes an essential productivity booster. So essential, in fact, that even for a 2 day website project, we relied heavily on source control.
But everything wasn’t smooth sailing.
Continue reading Building Software as a Team in TFS
Use source control when you need it
Especially for a fast project with a small team, sometimes its faster to work outside of source control. What? It’s true.
Here’s the deal: when you’re rapidly prototyping and building a website, it’s usually much faster to work on your small components in an isolated, focused ASP.NET website and then add your work to TFS once you’ve got your component working on its own.
This is very true for a solution with many projects, or a solution built on Sitefinity. You often don’t need the configuration hassle or build-time of the “big project” just to work on your own sliver of functionality. And since Sitefinity is based very “cleanly” on ASP.NET, you can just use a scratch ASP.NET website and “normal” ASCX user controls to quickly build and test something like a custom module before adding it to the master project. It can save you hours.
Here’s the workflow that we used for most of our Sitefinity development:
- Each team member had their own copy of Sitefinity and OpenAccess ORM
(IMPORTANT: Make sure each team member has the *same version* of whatever tools you’re working with. This will save headaches later.) - Each team member working on custom modules simply built and tested them in their own local environment. Most team members didn’t even use Sitefinity until they had a working UserControl in a “plain” ASP.NET website. Don’t introduce complexity until you have to.
- As custom modules were completed, they were integrated in to the “main” Sitefinity website in TFS, which was a simple process of copying ASCX files, sometimes copying some DLLs (or external libraries), and updating the web.config.
- As major updates were ready, we would FTP all changes to the staging web server.
- Schema changes were handled in the dev environment by the OpenAccess build step (we used forward mapping for our custom objects). To deploy them to staging, we used RedGate tools.
Be careful with Web Sites in Source Control
We had one disaster with source control that cost us a few hours during WAM weekend. Sitefinity 3.7, as you may know, uses the Visual Studio Web Site “project” type. The Web Site project is based on the file system and technically does not have a “project” file. That makes Web Sites easy to work with on their own, but they are potentially problematic when other project file-base projects are added to a solution.
It so happened that part of our team had built a couple of class libraries. Not realizing that the default items in source control for a “web site” lacked a solution file, they added the class library projects to the website. This hosed our solution file.
After a few hours of trying to clean-up the mess, we had this realization:
Source control, when used correctly, saves your team time.
Source control, when used incorrectly, can destroy your team productivity with a single check-in.
Lesson? Be careful with web sites. If you can avoid website projects, do. Web Applications are much more reliable in Visual Studio. If you can’t avoid website projects, make sure you add your other projects correctly to the solution file.
One more Sitefinity Special Consideration
If time is short, don’t add the Sitefinity folder to TFS. It has literally thousands of files. Checking those files in and then subsequently checking them out is a time consuming process. It’s actually much faster to just give each member of your team the Sitefinity folder that they can add locally for testing code from TFS.
The Sitefinity folder should be a “static” resource. You shouldn’t generally need to change the files in that folder. Upload it once to your staging site and leave it.
Eventually, you’ll want to add the Sitefinity folder to your repository so that it’s easy for new team members to check-out and work with your code, but in time strapped events like Givecamp, you may be better off following this advice.
Work Items and better teams
In 40 hours, there isn’t much time for creating work items- we relied on a big whiteboard to cover that task. In the real world, though, a big whiteboard isn’t the best way to create and track work items. TFS provides work item support, but the default Visual Studio tools for working with these items remind you that VS is a coding tool.
Enter the Telerik Work Item Manager.
Work Item Manager is a tool from Telerik that helps you be as productive with managing your work items as JustCode is at making you productive with your code. And we offer it as a free tool for everyone! If you’re working with TFS and you haven’t checked WIM out, I’d really like to know why. It’s a great way to maximize the productivity of your team…when you have more than 2 days to work on a project.
Okay. Enough boilerplate conversation. On to some of the implementation details. In the next part, I’ll talk about how CSS frameworks save you tons of time and why you should be using one. We used one. Find out which one in part 4.
