It is very fashionable to apply a single word to pretty much ANYTHING to try to get in on the latest trend. The current ‘Whatever-Ops’ trend (MarketingOps, ChatOps, OpsOps) is one such example. For a while, though, we’ve been having the word ‘Continuous’ thrown in front of a whole lot of activities in the software development world: Continuous Delivery, Continuous Improvement, Continuous Management. There’s a reason for this… repeatable processes are a key ingredient to predictable delivery. And predictable delivery means money in the bank!
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:
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!
On the fifth day of Christmas, my true blog gave to me:
Today I offer you some best DevOps practices for your delivery team. Do, or do not. There is no try.
Continue reading “Fifth Day of Christmas… Five Golden Rules”
Wednesday afternoon, while at the DevOps East Conference, I attended a Continuous Integration (CI) session delivered by Chris Riley (@HoardingInfo). Chris was sharing his past experiences with CI and how to best roll it out to all types of organizations.
I particularly liked his suggestion of putting the QA team front and center, as I agree that there are few groups better suited to caring about the end-to-end cycle of delivery.
During the session, Chris offered his definitions of DevOps, both the practice, and the movement. It was during this discussion of the ‘fluffy’ side of DevOps (people, processes, and journeys) that I realized I was definitely a Fluffy DevOps kind of guy.
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.
This week I got to see a demo of Infront’s Orchestrated Patch Automation Solution (OPAS). The software promises to automate away all the manual steps that operational staff need to perform to update servers and then validate that they are healthy after the update. This could put an end to the weekend work, or middle of the night, bleary-eyed patching of one server after another. Why stay up late when you can make OPAS stay up for you? 🙂