On learning new skills...

I'm your typical infrastructure guy - design the platform, run through the installers, use PowerShell to do post-setup and admin tasks, maybe script something to make a boring job easier - you know the drill. This DevOps thing is kinda cool to see working, but how does that fit in with the way I'm trying to do in my projects? As it happens, it fits in really, really well. We already use Agile methods in our project delivery team, and the Ops team have just adopted Scrum as well. The DevOps mindset isn't terribly difficult to adopt when you're already used to delivering small improvements often. What is different about all of this is, for me anyway, is the Dev part of DevOps.

I've had my PowerShell knowledge tested and expanded whilst working with this - first, by writing a deployment function to take what System Center Virtual Machine Manager does and making it fit into our deployment requirements and under source control; secondly, working on the SharePoint 2016 platform we've been tasked to deploy by using Desired State Configuration. I've had to learn about source control, about commits and why you attach them to work items, about injection, about the separation of infrastructure and application, the whole nine yards, and I'm not even halfway done, if you follow some of the guidance out there. 

One of the things I've learned during this entire process is that red in your PowerShell console isn't a Bad Thing. Not even close - it's usually helpful when dealing with a complex beast like SharePoint. Granted, some of the errors during testing haven't been PowerShell-based, and some have been really, really odd. 

For example, the Event Viewer on the primary application server logs Event ID 3351 in the Application Log (SQL Error 18456, State 5 (Invalid user ID) in the SQL logs), stating that the SP Farm account is a bad login. However, the account is present as a security principal in the SQL instance AND the SP_Config database. What? 

Turns out the issue was caused by the script execution speed beating Active Directory replication and adding in a tombstoned SID to the database. Slowing down the reset process during testing was all that we needed, but it caused a lot of head-scratching! 

But what we do is hard, right? As my esteemed colleague said to me, if you run it and it goes perfectly, first time - what did you learn? The fact that we can review and change the code, chipping away at the problem one red line at a time, that we can repeat it again and again and again until we get it right - I've found that it's really important. We learn by doing. 

I've been involved with this DevOps methodology for a month now, and I'm enjoying every minute of it.