While investigating options for deploying Sitecore to Azure, I found a TeamCity deploy plugin that supported FTP (among other things). Unfortunately, after trying to get it up and running I ran into the following 501 error while using FTPES (explicit FTPS):
“Failed to upload artifacts via FTP. Reply was: 501 server cannot accept argument”
Investigating on the server, I found the following in the IIS server logs:
“Client IP on the control channel didn’t match the client IP on the data channel”
A little bit of Google digging later, I found some chatter on the issue on the plugin’s GitHub issues list. That thread pointed to a patch build with options to specify Active versus Passive in the FTP mode. It turns out I needed Passive, but the original plugin download didn’t support it.
If you also need this functionality, this is the link to the plugin developer’s build which supports an option to specify Passive versus Active on the FTP mode:
With the release of TDS 5.5, deployments now support post-deploy actions with a few out of the box options. However, you can even add your own custom actions into the flow. With a little help from Hedgehog Sitecore MVP Sean Holmesby (Thanks Sean!), I was able to get this working using the following six easy steps.
Continue reading “TDS Custom Post Deploy Actions”
Those of you who have installed Sitecore in a scaled environment (i.e. multiple instances) know that the process can be somewhat tedious. To configure an instance to use a specific role, you need to manually enable/disable/modify config files to make the instance act as a delivery, authoring, or processing instance. Oh, do you also want to upgrade to the latest update? Be prepared to have to do it all over again.
While we wait for Sitecore to make this process a little bit easier, I decided that enough was enough and I wasn’t doing those steps anymore. Introducing the Sitecore Role Configs!
Inspired by the work in @kamsar’s SwitchMasterToWeb, the role configs capture the manual steps from those guides in a single role-specific file. Need to configure a processing instance? Drop the processing config file for your version of Sitecore.
Note: Hardening is not covered in these files, so keep that SwitchMasterToWeb handy!
At the time of writing, I’ve got Sitecore 8.0 Update 3 to Update 7 supported and will be working to get other versions in there as time goes by.
One day, I hope that the need for these files will be completely obsolete and I will laugh at how easy it is to deploy new roles of Sitecore. For now, though, happy deployments, and let me know if you find any issues and I’ll fix them up!
Team Development for Sitecore (TDS) supports the ability to manage your Sitecore roles within your TDS projects in Visual Studio. This ensures that important roles defined for things like workflow or other security needs can be deployed to all your environments.
Recently, I was building my packages for deployment to production and was going through the generated .update package and could not find my roles. No folders for roles, no files for roles… WHERE ARE MY ROLES?
Hedgehog support to the rescue!
I reached out to the fine folks at Hedgehog for some help and heard back the same day. Apparently, the standard Sitecore Update package format doesn’t support roles, so when Hedgehog added the support they did some sneaky things to make magic happen. The roles have actually been added into post deployment steps, and you can find the role definitions inside the file /_Dev/DeployedItems.xml.
The XML looks something like this:
<Role Name="sitecore\Keystone Multisite Manager">
This obfuscated CDATA content contains all the things you need to define the role in Sitecore. Pretty nifty!
When a solution is in operational support, handling ongoing changes in the Sitecore database can be challenging. System admins and content marketers need to be able to make changes in production authoring, the maintenance team needs to make quick fixes through all environments, and the development team needs to be able to build out new features. Here are some incremental options you can use to scale up your content deployments for development and operations.
Continue reading “Sitecore DevOps: Scaling content deployments”
I was recently working on some deployments that leveraged Team Development for Sitecore (TDS) projects and began receiving the following error on the build server:
C:\Program Files (x86)\MSBuild\12.0\bin\amd64\Microsoft.Common.CurrentVersion.targets (990): .NET Framework v3.5 Service Pack 1 was not found. In order to target ".NETFramework,Version=v2.0", .NET Framework v3.5 Service Pack 1 or later must be installed.
Local compilation with Visual Studio looked fine and the build server was able to complete successfully if I excluded the TDS projects from the build configuration. This pointed to a problem in the TDS projects themselves.
Further investigation yielded that this is a TargetFrameworkVersion issue within the XML of the TDS project files. In my scenario the project files had a value of:
If the build server only has the most recent .NET assemblies installed, it will not be able to compile this project. Luckily, there are 3 easy steps to fix this for any TDS project file:
- Open up the .scproj file for manual editing with your favourite text editor application.
- Change <TargetFrameworkVersion>v2.0</TargetFrameworkVersion> to <TargetFrameworkVersion>v4.5<TargetFrameworkVersion>
- Save the project file.
NOTE: You may have to repeat this multiple times within a single project file. I noticed that my particular TDS project had two instances of the TargetFrameworkVersion tag in the XML!