Team Development for Sitecore (TDS) is currently in beta, and is due to be officially released to the public next week. I've been lucky to have already played with the impressive list of new additions in v5.5, and loved the further improvements to my Sitecore development efficiency. Features like the new Delta Deploy feature, and the Auto Deployment of Content Files have me doing Sitecore development quicker than ever. One big new addition available in TDS v5.5 is the AutoSync feature... Another efficiency helper, where Sitecore changes get synced back to the TDS project automatically. It has been described as a 'new' feature.... But is it? Really, Auto-Sync has existed in TDS for a while, it's just taken on a new form in v5.5. Let me explain what I mean by this. Back in 2010 TDS v3.0 introduced the TDS <=> Sitecore Rocks connector. This connector meant that changes made using Sitecore Rocks were automatically synced into the TDS project. A developer would add templates, layouts, and edit content in Rocks.... and without doing any extra work, these changes were pulled in to the TDS project. Sure, it's not what we mean by AutoSync in TDS v5.5.... but that's exactly what it's doing... it's auto-syncing a developers changes into the project. 2010 huh? It's 'new' on a geological timescale.... but not on a development timescale. :-P But the feature updates didn't end there... In 2013 and 2014, Sitecore Rocks extensions were overhauled... And Hedgehog (more precisely TDS's main mastermind, Charlie Turano) worked closely with Sitecore (namely Sitecore Rocks' main mastermind, Jakob Christensen) to have the connector continue to work. Minor updates were made, and developers continued to benefit from these two great tools working seamlessly together. Then in 2014, TDS v5.0 was released. One of the new features that Mike Edwards created, and demoed here was a new set of contextual options that utilize the TDS <=> Rocks connector. (Jump to 24:40 to see this in action) This reduced round-trips between Rocks and TDS content trees for manually synced items. Filling the gap between AutoSync'd items, and new ones to be AutoSync'd that were previously excluded. Fast forward to now.... March of 2016, and TDS v5.5 is about to be released with 'AutoSync'. So item changes in Sitecore are automatically pulled into the TDS project. A great feature.... but really I see it as the existing AutoSync that's been around for 5+ years...just with added browser support. OK.... not all developers use Sitecore Rocks.... sometimes you just want to use Sitecore in the browser. Now TDS's AutoSync can be switched on, and the same auto-updating in your TDS project can take place. With that said.... I don't mean to down-play this feature at all. I too use the browser on occasion.... and even with the TDS <=> Rocks connector installed I can turn on this new AutoSync feature, and have everything automated for me, both from within Visual Studio, and from within Chrome/Firefox/Edge/IE?/Opera?.... It's time to Automate All the Things! and TDS v5.5 enables this with the new version of AutoSync. Charlie has done an amazing job with this feature... making it seamless, and minimally intrusive to the Sitecore instance. To get it that way, he's done amazing work... so me saying it's 'just added browser support' hopefully doesn't take away from that. :-)
From scheduling Razl scripts to sync changes between Production and QA environments to keeping logs from scheduled Razl scripts, our team has a few tips and tricks to make the Razl experience even better.
Setting up Azure staging slots, so the next release of our project can be placed there, allows us to deploy the new code to a private website (the slot), and test it before pushing it live. We are going to script this process to make it easier for the devops team to automate.
There are certain systems and processes that you can put in place to make a TDS Classic project run more smoothly. We're highlighting the best practices that our team recommends for getting the most out of TDS Classic.
TDS Classic can be used in many ways, but the goal is always the same: make development (and developers lives) easier. Whether it's using the Sitecore Package Deployer or using validators, following best practices can make your entire experience run much more smoothly.
When building an .update package with TDS Classic, the build might fail with no additional information. From increasing log verbosity to using validators, there are ways to minimize or prevent this type of error.
Our simple scenario includes 2 developers using TDS Classic and checking-in changes to source control. The Jenkins build server takes the changes and performs the build, and then deploys the created package to two Sitecore environments.
Each and every feature in TDS Classic is aimed at helping developers. Whether the feature is out front or running quietly in the background the goal is always the same: make the development experience better.
Feydra virtualizes all front end assets (css, js & cshtml) of a Sitecore instance. With Feydra, front-end developers can commit their changes to Source Control without requiring the intervention of a back-end developer. We call it a virtual sandbox.
Each version of TDS Classic comes with the same goal: to make Sitecore development and, by extension, developers, lives easier. Every feature in our products is aimed at making the process better - some of these features aren't quite as well-known as others, but they all help smooth and improve the development experience.
When working with TDS Classic, you will eventually need to deploy your items to a Sitecore instance and you might not want the default behavior of every item in your TDS project deploying every time. This is where the TDS Sitecore Deployment Property Manager comes in!
Feydra eliminates common roadblocks for designers and front-end developers working on Sitecore projects by getting them up and running more quickly and allowing them to use the development environment and workflow tools they prefer.