by Jason Yip - June 12, 2013
Why are we mapping that value stream?
As far as I can tell, the original problem that Toyota was addressing with "value stream mapping" (VSM) was to understand material and information flow in order to improve production lead-time.
by Scott Turnquest - June 6, 2013
To help us better understand how our release process has evolved over time, the Go product manager Marco, created the following video and shared it with us. I thought it was a fun way to see how our process has changed over time:
by Scott Turnquest - June 4, 2013
Ever since the Mingle team started working on its new cloud offering we made a conscious effort to improve our ability to continuously deliver valuable features and enhancements to our production environment. I expected that frequent deployments, tons of automation and lots of learning about Amazon’s AWS would come with the territory - and it did. What I didn’t expect was that I’d end up asking and answering so many questions dealing with when feature X or bug fix Y would be ready for testing and when it would be ready to be promoted to production.
by Pavan Sudarshan - May 10, 2013
My last gig as a tech lead was on Bums on the Saddle, an ecommerce startup where we had to get a working piece of software with minimal functionality to production within a week. We then had to follow it up with frequent releases and be done with the minimum viable product (MVP) in 8 weeks. After the MVP we had to incorporate feedback and the store’s backend needs. We signed up for all of this and more in a Lean Startup style gig.
by Sriram Narayan - April 19, 2013
Say we have a set up like the one below. We have two pipelines -- one for component-1 (C1) and another for component-2 (C2). C1 just builds off its source code in version control (VCS-1). C2 has its source in a different repository (VCS-2) and is also dependent (d3) on C1. In Go terminology, C1 has one upstream dependency d1 while C2 has two upstream dependencies d2 and d3.
by Mark Chang - April 9, 2013
Every time any change is introduced - application, database script, automated test, infrastructure, deployment script, configuration, etc. - the change should kick off a gauntlet of validation. The quicker you can find out if a change breaks something the better off you are and the more confidence you will have in your software. We tell the teams who want to go faster that they need to fail fast. We built Go to give teams the power to model and remodel a Build-Test- Release workflow so that they get super quick feedback on every change. And if something breaks, great, find it fast, fix it fast, and then run the new version through the gauntlet.
by Sriram Narayan - March 18, 2013
Fully versioned configuration is a prerequisite for fully automated deployment. By fully automated deployment, we mean the ability to deploy to a set of machines (physical, virtual or cloud) having nothing but a basic level of provisioning (OS, hotfixes, basic network and disk config).
by Sriram Narayan - March 14, 2013
As part of release 13.1, we have added a bit of functionality to Go’s custom command. Accordingly, the task menu item has changed from ‘Custom Command’ to ‘More’.