Last night I’m at the Brisbane .NET User Group Meetup at Microsoft HQ. The topic is “Building Mobile Apps – The Professional Way”. Andrew Harcourt of Readify (@uglybugger) delivers an Industrial Release Engineering master class.
The main takeaways for me are:
- Check my dependent node modules into revision control. Andrew prefaces this piece of advice with: “I’m about to start a religious war and walk away”, and follows it up by reminding us of the npm-polcalypse that left build systems that relied on npm inert. If you want your stuff to reliably build every time, then you need to have all the dependencies in your revision control and build system. I go straight home afterwards and take node_modules out of my .gitignore file.
- Typescript is the future. Yay!
This is the first time I’ve been at MSFT in 18 years, and I’m blown away by how much things have changed with respect to open source in that time. The 2006 Port 25 lab initiative has morphed into Microsoft Open Tech, and the open sourcing of .NET and the inclusion of open source technologies like Node.js and git. I manage to win two lollies by correctly answering questions – I have an unfair advantage: I’m a Node.js developer.
There’s a moment when Andrew asked: “Oh yeah, there’s some C# code in this app as well. Who wants to see some C# code?”
I’m the only one to put up my hand. Everyone else there is coding all day, every day in C# – it’s their daily bread. They want to hear about Node.js, gulp, and how Andrew puts it all together with Team Build and Octopus Deploy in a release engineering tool chain.
I recognise good release engineering when I see it, and this is good release engineering. I spent ten years at Red Hat, an open source software engineering company that started out as a release engineering company that sold mouse pads and t-shirts. Flamboyant JBoss founder Marc Fleury famously called Red Hat out as “third-party software packagers who fleece the open source community and don’t give anything back” (just before RHT threw down $330 million for his company).
I chat with some dev afterwards about release engineering practices at their companies, and the struggles they have to craft professional software with best practices. As a former manager I know what it’s like when a software professional wants to over engineer the hell out of something, and as a software engineer I’m also aware of the evils of premature optimization. And, an engineering slip-up in release management and deployment can bankrupt your company – just ask Knight Capital Group.
Here’s one for you – I once had nightly builds being checked in to a server in the US over ssh via a long-running process on a G3 iMac under my desk. It went AWOL one night when a cleaner knocked out the ethernet cable. More an annoyance than a show-stopper, but definitely not reliable release engineering.
What’s your best/worst experience with release engineering? Any places in Brisbane you’ve worked that have stood out as an example of best practices?