I am currently on a team to migrate several large farms to AWS Cloud and I have utilized SharePoint DSC and SharePoint Reverse to great success.
My managers were quite impressed with the technology and want to know more about how to utilize DSC. I have been vague with my answers. I have been telling them “Automate as much as we can so it will take fewer techs to manage more” ( I work as NASA so anyway we can save a buck is music to their ears.)
I guess I am having a hard time applying a DevOps mindset to SharePoint. Once its installed and running, there is mot much to do after that. We are not developing custom code or anything like that. we are using all features out of the box with a few App store applications for very specific projects
I have come up with some use cases such as:
Service patch updates
Configuration changes across all servers in a specific farm.
Ensure Production and Staging are duplicated accurately
Migration of features from Staging to Prod
I know there might be more use cases and I would love to hear your ideas. Has anyone else applied DevOps mindset to sharepoint?
Well, to be clear, DevOps is a “tool” you use when your goal is to rapidly iterate and deploy again and again and again. There’s no need to “DevOps” if you’re not doing that. It’s like saying, “I’m having a hard time figuring out how to apply a bazooka” when your goal isn’t blowing up buildings and stuff.
DSC isn’t a patch management tool; WSUS and SCCM are far better-suited.
Configuration changes - sure.
Configuring environments in sync - sure.
Migrating features - mmmmyyerrrggh maybe. Depends on what you mean.
But this isn’t DevOps, per se; it’s automation, yes, but the two are not the same thing. You can certainly use DevOps-like principles, and automation is one of those.
Oh, I’ll point out - regarding “syncing” environments and maintaining consistency between them.
The difficulty you run into is that you stand up, say, a Prod and Dev environment. They’re in sync at that moment. But they’ll continue to diverge from there; sure, you can add some stuff to a DSC config in Dev, test it out, and then migrate it to Production if you like it. But the nature of any long-running service (like SharePoint) is that it’s going to drift in unpredictable ways; Prod will be using more disk space, have different operating parameters, etc. So it’s likely not ever going to be completely brain-free.
DevOps leans a little more toward, “blow away the entire environment and rebuild it from the configuration, every single time.” Which, notably, you CAN do with SharePoint, if you’ve architected it Really Freaking Well. That’s the cattle vs pet argument; if you’re like, “OMG, I could never blow away the production server and rebuild it successfully,” then you’ve got a pet, and you’re not really going to DevOps it. But if your server is abstracted from how people access it (DNS, load balancers), from its data (distinct SQL Server, file storage), etc., then the SP server itself needn’t be all that special or unique. In which case, you can take a much more DevOps-y approach, which brings with it other benefits (like, “I’m not troubleshooting this, I’m deleting it and starting over with a config I know works”).
I concur with your thoughts. I am trying to apply a bazooka.
What I think I really need to focus on is automation. I think our environment is more suited to the “If I can’t fix it in 30 minutes, blow it away and recreate” but at the web application / site collection level. That I can automate fairly easily with Powershell and DSC.
Another unrelated issue is that I am getting really good at DSC and I am anxious to show off,even if the environment is not really suited for it.
Maybe I should learn to be a little bit more humble.
Also, keep in mind that speed isn’t the only gain you get from automation - you get consistency, reliability, auditability as well. Every configuration change that’s done by hand is another chance for human error to creep in, and there is no deployment checklist in the world that can prevent a fallible person from the occasional typo.
With DSC (or for that manner any structured configuration management) you can say with absolute certain that this is how the system was before, this is how it changed and at what time, this is what happened when the exact same change (which we know for a fact because we applied the same files) happened in test, and these are the automated test results to validate all of the above. Optimizing for speed can fail to get traction in small environments where you’re just trying to save a few clicks. Optimizing for reliability is something that even a small environment can get behind.
That said, Don is very right when he discusses drift over time. SharePoint is incredibly stateful and naturally changes quite a bit if it’s getting any sort of use. However, it can be a good exercise in its own right to separate the stateful content of SharePoint from the (in theory) persistent configuration of the environment itself.
