We continue with our how has the Ranger community evolved … series chat. Like many other teams within our organization and early adopters from the communities, we are “eating our own dog food”, all teams using bleeding edge products 24×7 for all our projects. It enables us to evaluate new features and services, provide early and real-world feedback, isolate any gremlins, and ensure that our users have the best experience when the products are released.
We have, for years, used our own guidance and our products to support our teams and projects. Looking at our dashboard below, you will notice a variety of dog foods:
- Visual Studio Team Services has been our one and only software lifecycle home since 2011.
- We use a variety of Visual Studio Team Services extensions.
- We embrace DevOps with our continuous integration and continuous delivery pipelines, deploying to separate environments (sandbox-two for DEV, sandbox-one for BETA, and public marketplace for PROD). See Applying DevOps to a Software Development Project for details.
- We’re using one team project to rule them all. See TFS Planning, Disaster Avoidance and Recovery, and TFS on Azure IaaS Guide for details on the guidance.
- We’re using both the TFVC and the Git version control system.
- Kanban is the choice for most of our self-organizing and autonomous teams.
Let’s listen to what three of our Rangers have to say about the dogfooding:
The early access to new features allows me to work with new features before customers see them allows me to keep my expert status. The only problem with being on the cutting edge is that when I work with an ‘older’ TFS version at a customer I’m sometimes completely lost.
I also hope we help the team with our feedback and testing. The same is true for our extensions. Every time I see the Countdown Widget on the ALM Rangers or ALM Champs I feel a little bit proud Dogfooding the extensions ourselves helps finding bugs and adding new use cases. – Wouter de Kort
As the name state, the rangers are field workers, living and feeling the needs of users and getting a strong sense of what is going on outside of product walls. Through early exposure of new features, we can help users and admins deal with real world dilemmas. As we are using most of the features, we can typically point to (potential) failures and propose improvements.
Our extensions serves our main goal by offering, yes you guessed right- gap filling solutions, it is totally a community contribution. The great thing about it is, one can be sure that even preview extensions are A-list extensions. Quality wise , they were tested, verified and of course will be well maintained. It is very important in a marketplace where anyone can upload extensions, the conservative users can install DevLabs extensions with a high level of confidence it won’t break their environment. – Shmulik Ahituv
We can make sure that new features don’t only work but also ‘feel’ right for when customers get them. The best feedback the engineering team can get comes from actually using bits, rather than only being able to say what we think would work and how we think it could work well. We’re able to identify where some usability issues could be and also stand a better chance of finding our bugs before customers do. – Gordon Beeming
In the old days miners would take Canary birds with them into the mine tunnels. They hoped that the birds would detect dangerous gases, for example carbon monoxide, before they would have a fatal effect. They were the miner’s friend and early warning system.
We often call ourselves the Canaries, living in the inner most deployment ring of many of our own products, including Visual Studio Team Services. While we are often impacted by outages, bugs, or unexpected features, we know that everything we detect, is something that will not affect the early adopters in the next deployment ring, and especially the users in the public release.
A funnel is another great visualization of the release pipeline across rings. Using feature flags (Controlling exposure through feature flags in VS Team Services) the Canaries and early adopters can be exposed to all the new features, whereas the production users can be shielded from features that still require a bit of “fit and finish” polishing.
Here’s a recent real-world snippet of a recent Canary communication thread:
- Wed 2016-09-21 14:56 – Rangers –> We are seeing this error in SU0 when installing Colin’s ALM Corner Build and Release Tools extension on all of our accounts, while other extensions install fine …
- Wed 2016-09-21 15:35 – Feature team –> I’m investigating.
- Wed 2016-09-21 16:34 – Feature team –> I just pushed a fix. Can you try again?
- Wed 2016-09-21 16:42 – Rangers –> Bingo! Thanks for the quick fix.
- Wed 2016-09-21 16:51 – Feature team –> To all: I pushed a fix.
That’s a quick fix and deployment for an issue that remained within the circle of Canaries. No impact to early adopters or users
What do you think about dogfooding and early-warning canaries?