Blind Not Dumb (Posts about releng)https://www.feoh.org/categories/releng.atom2024-01-21T01:02:41ZChris PattiNikolaThe Joy of DevOps (Or, Return of the Living Generalist!)https://www.feoh.org/posts/the-joy-of-devops-or-return-of-the-living-generalist.html2013-07-31T16:09:00-04:002013-07-31T16:09:00-04:00cpatti<p>One of the things I have always enjoyed about what I do is that I have, from pretty much day 1 in the technology industry, worn many hats.</p>
<p>No matter what my job title said, I have always done pretty much whatever needs doing whether or not it crosses into what others might consider a discipline that's not in my job description.</p>
<p>I like it that way. I enjoy picking up new skills, flexing my mental muscles in new ways and exploring the uncharted territory that is every new technology to rise out of the primordial ooze of Github (Or Sourceforge before it).</p>
<p>Way back in 1992 when I got my first job in the technology industry, I met a very wise man named Dale Dougherty (I hope I'm not mangling the spelling, it's been over two decades! (If you're out there Dale, give me a holler will you? I'd love to get back in touch) and when he asked what it was that had driven me into technology, and after I told him in the naescent, halting terms I could form at the time he smiled and said "Ah! You're a generalist. Unfortunately, those are undervalued these days. It's a great shame" or something to that effect.</p>
<p>Boy was he right. For the next 20 years I would end up doing tech support, sysadmin work, software development, and finally release engineering.</p>
<p>The industry began throwing up high walls and fences around places and processes we all used to take for granted. "You can't do that, you're not a <strong>developer</strong>!" "Only <strong>sysadmins</strong> get root and access to production machines!" "You're a <strong>release engineer</strong>, not a developer!" Ad infinitum.</p>
<p>Fast forward to 2009 when folks came up with the DevOps manifesto, in which a positively radical idea is proposed: All these distinctions are useless. They do nothing to make organizations more efficient, and instead bottleneck and pigeon hole good people, keeping them from feeding their passion.</p>
<p>Needless to say, I love it here. I get to bring all the experience I've accumulated in 20 years hard labor in the code mines to bear, and it feels <strong>really</strong> good.</p>
<p>I'm building infrastructure in the cloud, learning about load balancing, high availability and I've just barely begun.</p>
<p>As much as the layoff I just went through was painful as they always are, that moment of dislocation pales in comparison to the satisfaction I feel in what I have accomplished in the few short months I've been doing this, and the <strong>incredible</strong> excitement I feel as my horizons have been exponentially broadened.</p>
<p>As I write this, I'm several thousand feet up, bouncing along over the clouds on my way to Santa Clara, California for the annual Velocity conference.</p>
<p>It's an incredible meeting where some of the best and brightest in our industry come together to make the web go faster and more reliably, and I can't wait to dive in and start learning :)</p>
<p>[<em>Update: I'm posting this weeks later, because things get hectic. Such is life. Velocity was amazing. Look for another post on that coming soon.]</em></p>3 Things Microsoft Should Do for Release Engineershttps://www.feoh.org/posts/3-things-microsoft-should-do-for-release-engineers.html2010-01-28T13:39:00-05:002010-01-28T13:39:00-05:00cpatti<p>For the last year or so I've been working at a 100% Windows based enterprise development shop. They ship a fairly large and complex application for health insurance providers, which draws on many of the core technologies in the Microsoft enterprise stable.</p>
<div class="line-block">
<div class="line"><br></div>
<div class="line">This post highlights a few things that make working in this environment a whole lot more onerous than it needs to be in my opinion, so let's get started.</div>
</div>
<section id="installers">
<h2>1. Installers</h2>
<p>The Windows installation landscape has been a bleak one indeed for a very long time. Tools like Installshield with their own proprietary languages like InstallScript make installer development unnecessarily painful and baroque. Is there <strong>really</strong> any reason I should be programming in a language with no real data structures to speak of in 2010? Even flow of control is handled in a way I can only describe as baroque. There are methods/functions, but the main body of your installer's code has to jump around everywhere using goto. What a mess.</p>
<p>There is hope on this front, in the form of <a class="reference external" href="https://wix.sourceforge.net/">WiX</a>, the Windows Installer XML toolkit, which allows developers to iteratively build and design their installer along with the regular development process. Right now however the learning curve seems incredibly steep. Perhaps Visual Studio could generate a template WiX project to get people started?</p>
<p>I'd also love to see some thought given to simplifying the deployment model for things like <a class="reference external" href="https://msdn.microsoft.com/en-us/library/ms685978%28VS.85%29.aspx">COM+</a> - which feels to me like a magic black box with myriad buttons and levers, all of which are a bear to get right at install time.</p>
</section>
<section id="builds-scm">
<h2>2. Builds/SCM</h2>
<p>MSBuild needs to have <strong>dramatically</strong> better documentation, and to a lesser extent so does TFS - they get the broad bits right - everything you could want to do through the UI is covered, but process automation using scripting / command line tools gets substantially murkier.</p>
<p>In the 'credit where credit is due' department, the TFS team has been incredibly responsive on their forums, and that's what's helped us get by so far, but there's no substitute for first rate docs.</p>
</section>
<section id="infrastructure-scripting">
<h2>3. Infrastructure Scripting</h2>
<p>As of right now, there are a thousand different interfaces to accomplish the same thing, and for complex configuration tasks like configuring IIS at install time, the possibilities can be dizzying. I would like to see Microsoft choose <strong>one</strong> mechanism for run-time system/software configuration and document the heck out of it.</p>
<p>Kudos to the <a class="reference external" href="https://blogs.msdn.com/powershell/">PowerShell</a> team and <a class="reference external" href="https://technet.microsoft.com/en-us/scriptcenter/dd901334.aspx">The Scripting Guys</a> for making great strides in this area. PowerShell is a really nice environment for all kinds of scripting, and I look forward to the day when we can eliminate VBScript from our installers entirely in its favor, but we're not there yet sadly. The object pipeline is one of the more powerful concepts in the modern scripting milieu, and I think Apple and the UNIX world could take a page from PowerShell's book in this regard.</p>
<p>Being a release engineer in a Windows world presents some very interesting and different challenges for someone coming from a UNIX background like myself, and with a little bit of emphasis and effort on Microsoft's part, surmounting them could be a whole lot less painful.</p>
</section>