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!
This past Tuesday I attended a Webinar led by ALM Ranger and Microsoft MVP Esteban Garcia (@EstebanFGarcia). The topic? Azure and Visual Studio Online (VSO), specifically around deployments (or so I thought). There was more content in this session than I expected to get, that’s for sure!
My primary goal in attending the session was to get a better picture of how deployments worked from VSO code repositories into the Azure cloud, but as a bonus there was also coverage of VSO load testing functionality, as well as Application Insights. Continue reading “Visual Studio Online and Azure deployment”
We have all seen the magical project plans that have no grounding in reality. Schedules are far too aggressive, scope is beyond what the team can handle, not enough resources available to properly run the team… all to meet some magical “hard deadline” that has been imposed seemingly without any reason.
The folks in charge of these plans are not evil – they may just have somebody enforcing a deadline on them and are trying every possible thing to draw a picture to meet that deadline so they don’t get fired. These people are members of our team and we cannot leave them struggling alone. As architects and technical subject matter experts, we need to help our team members make their complete nutbar of a project plan into something that makes sense in the real world we live in.
Continue reading “How I know a project plan is total nutbars… and how it can be fixed”
I had planned on kicking off a short series on how to tackle the challenges of Sitecore Continuous Deployment, but after I had written my post the Sitecore Virtual User Group (SVUG) held an online Q&A presentation by Jason Bert on Continuous Integration & Deployment. The presentation is a great introduction to the concepts and challenges.
Some notes on the presentation
TeamCity (build), Git (source control), Octopus Deploy (deployment), and Sitecore Courier (create update packages).
Continue reading “Sitecore Continuous Deployment: Video presentation from SVUG”