Be a Speaker at PowerShell and DevOps Global Summit 2020!

We are so excited for the 2020 PowerShell and DevOps Global Summit! We’re about halfway through the CFP season and are still looking for your awesome submissions. If you are hesitating, please don’t… think seriously about submitting a topic or two. To help you, we’d like to give you some ideas about what makes a submission stand out (and what doesn’t).

• Something Unique… We’re looking for a new spin or twist on an old (or new) topic. If something similar has been done at a previous Summit, think about how you’re doing something different from what’s previously been presented. DevOps topics are always popular, but what new thing are you doing with your source control, your testing, or your build pipeline?
• Failures… Alternatively, is there something you started out to do and at some point, figured out that you it wasn’t going to work the way it was planned? If you’ve had some good lessons learned that you think would benefit others, we’d love to hear about it.
• Broad scope vs. deep scope… If you’ve done a snack “bake-off” and could talk about chips, cookies, and crackers, this session would be attended by folks who prefer chips or cookies or crackers. However, a session that is only about cookies might only be of interest to Rambling Cookie Monsters. If you’re a subject matter expert on chips, though, and can show how to use chips to build a house, that would have that uniqueness factor we’re also looking for.
• Multiple submissions… Multiple submissions on different topics help us select a wide variety of topics. It’s hard to say from year to year what topics will be popular. For example, we had a lot of Git and Pester submissions last year… not so many this year. We’re looking for variety so submit as many ideas as you have.
• Something that wasn’t selected last year… We may have really liked your submission last year and it may have simply been on the bubble. You’re only up against the submissions that we’ve seen for this year, so if you had a submission from last year that you feel passionate about and is still a hot topic, please submit it!
• “Post OnRamp” submissions are welcome… We have a graduated class of OnRamp students from last year who we want to continue learning. Therefore, we’ll be looking for a small number of sessions at this level.

Some additional things we’d like to add:

PowerShell and DevOps Global Summit 2019 – Post-CFP Thoughts

Now that Warren Frame and I have finally come up for air after reviewing all the submissions for the 2019 PowerShell and DevOps Global Summit, we wanted to send a great big THANK YOU!!! to all who submitted.  You all definitely made our job challenging and we think we have a fabulous lineup for this year’s show!

Many of you have asked for feedback regarding your submissions, and while we would love to send everyone individualized feedback - with the sheer number of submissions, that just isn’t feasible. 

PowerShell and DevOps Global Summit Recap

Now that I’m recovered from the 2017 PowerShell and DevOps Global Summit, I just wanted to take a moment and talk about my experiences at the conference. It was my first time attending this conference and it was also my first time speaking. Both “firsts” contributed to a range of emotions throughout the long and exhausting week.

I came in to Seattle late Friday night and expected to go straight to the hotel and to bed. Being from Eastern Daylight Time makes for a long day and late night when your expected hotel arrival time is 10pm local time (or 1AM your time). However, PowerShell friends and community members, some of whom I knew from previous conferences and some of whom I was just meeting for the first time, greeted me. Some stayed up and waited for me to arrive – even with an already-closed hotel bar and many respective time zone differences. They greeted me with an overwhelming sense of community and friendship, and that was a defining moment that I’ll never forget. Even though I was exhausted, I found myself staying up for a couple more hours chatting with folks who were already there.

DevOps: A Career Changer

Once upon a time, there was this woman at a TechMentor conference a few years ago, sitting in the front of the room during the “Don and Jason" show, a not-quite-scripted discussion on various “lightning” topics.

The topic at that moment was DevOps, and this woman was asking for advice on being an advocate for DevOps in her company.

Her company had just been acquired, she explained, which meant that the atmosphere was ripe for change, but the culture of the company they had been acquired from was very change-resistant.

No "Easy" Button for Configuration Management

A discussion in one of my Slack channels caught my eye today around someone’s reflections in a github repo regarding DSC. The posted comment that introduced the link was titled “DSC from a newbie perspective”, and I thought “Oh? I’m a newbie too, I wonder if we’re thinking the same things.”
A little history is probably needed on my “newbie” status with DSC. I went to the Tech Mentor conference in March, where I spent most of my time in sessions learning DSC. I was hooked, but knew I needed much more in-depth training to make it something that would be useful to me in the real world. So I set a goal of learning DSC in depth about 4 months, so that I could attend DevOps Camp in August, and be able to converse intelligently about DSC, Configuration Management, and DevOps in general. And with some help from friend and mentor Jason Helmick along with blood, sweat, tears, and 10-15 extra hours a week spent on just DSC, I made it to DevOps Camp and managed to follow along and join in the discussions.
I’ve got about 6 months of DSC experience under my belt at this point, but I still consider myself a “newbie” in the grand scheme, so I fell hook, line, and sinker to go check out the comments here:
https://github.com/18F/azure-sandbox/blob/master/dsc/README-dsc.md
I’m not an expert in Chef, so I won’t comment on the comparisons between the two. But while two weeks may be long enough to do a quick comparison between a product you know something about (in his case, Chef) and a product you are vetting against it (DSC), it isn’t nearly enough time to come to a conclusion like “DSC is too immature to even consider as a stopgap”.
Reading on, the reasons for liking/hating DSC seem to be the reasons for hating/liking Chef. Not wanting others to need to deal with learning Ruby was mentioned as a plus for DSC.  But it also seems like the poster wanted or expected DSC to be easy so that folks didn’t have to learn Chef, and was disappointed that it wasn’t.
There’s no “easy” button - if there really were an easy button for automation and configuration management, we’d have all the resources ever wanted neatly packaged and consumable, but the building of the platform and the tooling surrounding the platform takes time, people, and effort. So build and submit a High Quality Resource Module, or fork and fix some of the “awful error tracking”.  Some of these comments and feedback are really quite legit – but the points that need to be made and worked on are lost under the lamenting that DSC doesn’t have an Easy button.

Unit Testing is “Pestering” the Hell Out Of Me

About a week or two before Devops Camp, the attendees were asked how much experience they had using Pester, because another attendee was preparing a discussion on Pester and wanted to gauge the other attendees’ comfort level. Learning Pester had been on my to-do list for a while, but I had procrastinated on it for far longer than I intended. I answered “Beginner” - although “complete and utter newbie” would have been more accurate - and I vowed to spend some quality time looking at Pester before arriving at camp.
There are some really great resources out there devoted to Pester, from beginner to intermediate to way-over-my-head. I read articles and watched videos. And I understood, in a conceptual kind of way, how to use Pester. Describe, Context, It, Mock, Assert-MockCalled – I understood what these things were used for. The examples made sense. I was ready to move on to trying it myself. But here is where I stumbled and recovered, and I would like your feedback and opinions on my discoveries.
I took a piece of code I was currently working on and decided that a small function in that code was the perfect function to attempt my first unit test on. I mean, it was the tiniest little function - 7 lines of code! What could possibly be easier? Right?
Boy, was I wrong. The struggle IS real.
In a nutshell, my function really is 7 lines – an If/Else statement and a For-loop – and inside each is an external call to an Active Directory cmdlet. Those would definitely need to be mocked. After all, we know or assume that Set-ADAccountControl and Set-ADObject do what they are supposed to. I was stumped at where to even start because after mocking these external calls – there isn’t actually anything left to the code!
Even after a wise person told me that “This probably isn’t a great example of a “Pester 101” example”, I was still determined to figure out how to write a Pester test to test this function, but I needed to set aside my thoughts of “I can’t figure out how to write a Pester test for this” and instead, start with “Figure out how to write a unit test for this.” My brain freeze wasn’t about Pester – it was about unit testing. What do I need to test? My next step was to do some reading up on general unit testing concepts.
I’m not opposed to buying a book on testing concepts, but I wanted some quick answers and not a research project just to get me started. I turned to “Dr. Google” and I found some useful definitions, both formal and informal, on what unit testing really is. But it wasn’t until I found a comment buried deep in a StackExchange forum post that I realized what my next steps were.

Microsoft did WHAT?

Unless you’ve been living under a rock for the last couple of days, you already know that Microsoft announced last Thursday that the shell/scripting language formerly known as “Windows Powershell” is now supported on Linux and MacOS and that Powershell has been open-sourced. And for days, thoughts of “how can I use this?” or “I wonder if ‘x’ will be supported” have been flying through the minds of every system architect as we internally grapple with the possibilities of what could be, while at the same time trying to understand Microsoft’s motivation for this radical change.
Only the change isn’t so surprising if you think about the changes that Microsoft has been making leading up to this announcement. Separating Powershell Desktop Edition and Core Edition in WMF 5.1. Announcing SQL Server on Linux – after all, IT professionals are going to need a way to administer that SQL instance and it isn’t going to be through a GUI. Supporting Powershell on Linux seemed like a logical next step.
But it is likely just a step along the road to heterogeneous system management. Microsoft Technical Fellow and Powershell inventor Jeffrey Snover isn’t at all secretive over the fact that the vision is built upon Microsoft’s Operations Management Suite (OMS), a suite of automation and management tools that needs to be able to configure, control, manage, monitor, and self-heal a workload that runs anywhere and on any operating system.
From the perspective of a system architect that isn’t typically on the bleeding edge of technology, I am still extremely excited over this announcement. Why? The possibilities seem endless. For one, applications that run on either Windows or Linux or a combination of the two can now be configured by the same language, or maybe even the same set of well-designed scripts. Second, the possibility of using Desired State Configuration (DSC), or third-party tooling such as Chef or Puppet in conjunction with DSC, means I can keep *all* servers in compliance with their configurations using the same tooling. Third, what Devops engineer wouldn’t love having spent a few years learning a scripting language like Powershell only to have its reach extended to other platforms? This change invariably makes us more valuable to the company by being able to take on additional management responsibilities by using the skills we already have. It can then lead to even more cross-platform learnings and opportunities. I definitely plan to learn more about Linux and how I can help build cross-platform tools. If you have similar interests, here are some great resources to get you started!
https://www.pluralsight.com/courses/essential-tools-red-hat-enterprise-linux
https://www.pluralsight.com/courses/linux-networking-advanced-lfce
I haven’t even scratched the surface of thinking about all of the ways I want to take advantage of Powershell on Linux, and I have lots of exploring to do to find out what can or can’t be done – but the energy of the entire Powershell community over these changes certainly carries over to me as well. I’m excited to find out what is possible, to build what may not have been possible, and to contribute back to the Powershell community. So kudos to you, “new Microsoft”, for energizing the entire community of Powershell enthusiasts. I can’t wait to see what’s next.