At Unity, we’ve been spending a lot of effort recently looking at our build times. One of the topics that came up is lumped builds. I realized during all of this (and while doing my own research of course) that many people are lacking a clear understanding of what lumped builds gain you, and what they cost in return. What are lumped builds? Lumped builds are known by a few
Yesterday I was attempting to relax by browsing random things on the internet (usually a mistake, I know), and I stumbled upon an awesome white paper by Arnon Rotem-Gal-Oz about the 8 Fallacies of Distributed Computing. These are so obvious yet so profound I couldn’t help but write up a quick blog post about them. They’re especially relevant for modern day build engineers and tools developers — certainly relevant to the Build Automation
DISCLAIMER: This blog post is now several years old and it should not be used as a source of current advice. The landscape of version control, and DVCS in particular, has changed a lot in recent years. Not too long ago, @CorporateShark asked for a blog post about Unity’s experience using Mercurial for version control. This is that blog post. NOTE: Throughout this post, I use several terms that assume knowledge of DVCS in
Most people reading this know that I lead the Build & Release Engineering team at Unity Technologies. On Unity’s company blog, I’ve posted about our in-house build automation / CI solution, Katana. I wanted to write more about this project, and go over a few key elements as to why I believe it has turned into a successful project for Unity. First of all, if you haven’t read the blog post I wrote
I recently traveled to Phoenix, Arizona to give a talk about Build Engineering. The talk was titled, “Build & Infrastructure Engineering: What It Is and Why You Need It”. It covers the history of the Build & Release Engineering area at Unity (from 2014 to the current state in 2014), and then follows with an overview and introduction to the “5 Pillars of Build Engineering” and what they mean in
In a previous post, I wrote about what build engineers actually do. A related question is, “What makes a good build engineer?” Obviously this is subjective, but I can share my opinions based on my particular skillsets that are useful in my job as a build engineer, and the qualities I look for in prospective candidates when looking to expand my team. When trying to answer this question, an important thing
I wrote a blog post on our company blog about how we used Buildbot, and open-source CI framework, to build Katana, our internal continuous integration / build automation system.
The responses to this stack overflow question I stumbled upon made me realize that many people may not actually understand what build engineers actually do. Being a build engineer myself, I’d like to share my view. The definition of build engineering of course changes from organization to organization. From my perspective, a build engineer’s role is simple: our job is to keep the wheels turning. And as software solutions grow in size
So it’s has come time for your team to pick a new version control system. Perhaps your team has outgrown the CVS server or maybe someone lost the keys to your Vault server. Or maybe someone has wised up to the idea that backing up software by creating zip files and storing on a network fileshare (yes I’ve seen this — oh, the horror) doesn’t work so well. In any case, you’ve decided you