Blind Not Dumb (Posts about tfs)https://www.feoh.org/categories/tfs.atom2024-01-21T01:02:42ZChris PattiNikola3 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>