During development, your team makes a lot of changes to fields, templates, presentation details, and various other elements that need to be tracked, verified, and deployed. You need a way to source control those database changes, and then make them available to your team to test. Here’s how to accomplish that using TeamCity and Team Development for Sitecore (TDS)!
With your content items now in Source Control, you can start getting your database changes deployed along with your build.
Note: This assumes you are automating your file deployments to push code changes out to your environments. If you aren’t yet, you should be! Look for my upcoming posts on setting up deployment build configurations.
In order to get TeamCity to be able to deploy, there are a few things you need:
Your Sitecore content changes are just as important as the code you are writing for your solution, and that means you should be tracking those changes in source control. Your team will be making a lot of changes to fields, templates, presentation details, and various other elements for which you will want version history. This is where Team Development for Sitecore (TDS) comes in.
Team Development for Sitecore
Our teams use Team Development for Sitecore from Hedgehog Development to create .NET TDS projects to source control the changes we make in the Sitecore database. There’s a great guide that Hedgehog posted online on how to get started with TDS projects in .NET, but here are the basics of how you get set up:
Aaron Bjork made a great presentation at ALM Summit 2011. I’ll be providing my insights into using TFS 2012 on projects in some upcoming posts, but I think Aaron did an awesome job of explaining some of the agile management issues, as well as showcasing some of the new features for agile management in TFS 2012.
So you want to transition to agile, and have started reading about how there are only a few roles in an agile team: Scrum Master, Product Owner, or Team Member. In particular, you may be getting thrown off by this line from the Scrum Guide:
Development Teams do not contain sub-teams dedicated to particular domains like testing or business analysis.
If you’re a purist adhering to the letter of the law, this means you can’t have anybody in your team that is performing only one function, like a quality assurance analyst. However, “Being Agile” is about learning, changing, and improving, not being rigid. To succeed you need to take the framework, your team, and what works for you and adjust from there.
In a world of deadlines, tight budgets, and high expectations, sometimes we need that superstar on the team that can “get it done” so we don’t make our clients look bad. On the many teams I have led, this superstar has shown up in a few different incarnations:
The Hare You want it done by 2pm? No problem. The Hare has no issue with short deadlines because the Hare can get it done in 15 minutes. What’s that you say? The senior team that estimated the work thought it would take at least 2 days? No problem, the Hare still thinks it can get done in 15 minutes. Lo’ and behold, 15 minutes later everything has been coded up, checked in, and the Hare is off to save another project from certain doom. The fact is that it hasn’t been tested, and maybe not 100% of the requirements are in there, and perhaps it has a few paths where a nice 500 error gets served…but that’s not a problem, because that’s what the rest of the team is for, right? Continue reading What type of agile superstar are you?→