![]() We can also deploy just to GitHub staff, which we do for testing changes before releasing them to the public, by running. scriptDeploy.ps1 production, is all it takes to build, package, and deploy a new GitHub for Windows release. I, the bright-eyed, bushy-tailed newbie, got to work automating the process. So Paul opened this issue in our GitHub for Windows repository:Įven now, looking at that release process makes me cry. In fact, Paul was away my first week, so we weren’t able to ship an update we had all ready to go! When I joined GitHub back in March, shipping GitHub for Windows to our private beta group was a completely manual process, and Paul was the only one who knew how to do it. So, how do we do it? Automate everything (for us)Īs I said earlier, shipping often requires that shipping be automated. We work hard to make our updates as small as possible and to release them quickly, and I think the numbers bear that out. That cluster of releases down in the bottom-left corner near the origin is exactly what we want. Here’s a graph that shows all of our updates to GitHub for Windows thus far, with days since the previous release on the X axis and commits since the previous release on the Y axis: ![]() 72% of GitHub for Windows updates so far have contained fewer than 50 commits. That’s 47 commits per release on average, with a median of 41 commits per release. We’ve made 1,176 commits on our master branch since our first release. The story is largely the same if you look at releases in terms of the number of commits that went into each release. A full 75% of our updates so far shipped in less than 7 days. That comes out to about one release every 5 days, on average, and the median time between releases is only half that, 2.5 days. I said above that we’ve shipped 25 updates in 4 months. Let’s see how we’ve been doing with GitHub for Windows. We want all these same benefits for our native apps, too! But we don’t think shipping often should be limited to web apps. gets deployed hundreds of times each day. There will be another one soon, so make that code shine! If your pull request isn’t ready to be merged in time for today’s release, relax. And by shipping updates so often, there is less anxiety about getting a particular feature ready for a particular release. This raises our bus factor, and also democratizes the process of shipping so there aren’t “gatekeepers” who must sign off before any software goes out the door. Shipping frequently also requires that we make it downright simple to ship by automating it, so anyone can do it. For example, the more frequently we ship the less likely it is for large numbers of changes to build up between releases, and shipping a small release is almost always less risky than shipping a big one. Shipping rapidly is important to us for so many reasons. We think it’s so important to ship often, we even have a shipping mascot and matching emoji (:shipit:). One release per week - for a desktop app?!Īt GitHub, we ship a lot. That’s more than one release per week, for 17 weeks straight! Here’s how we do it. We’ve shipped 25 updates to GitHub for Windows in the 4 months since we first launched.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |