Freigeben über

Understanding the Visual Studio ALM Rangers

  • Artikel

Mission

The Visual Studio ALM | DevOps Rangers provide practical guidance, experience, and gap-filling solutions to the developer community.

aka.ms/vsarmission

Core values

As a team the Rangers have come to value the following:Razor sharp focus onquality and detail on the work we do
  • Favor simplicity and low tech over complexity
  • Expect and adapt to change, delivering incremental value
Accountability and commitment
  • Actively manage the project triangle attributes: features, bandwidth and cost
  • Never go dark … always share the good, the bad and the ugly with the team
Non-stop and unrestricted collaboration
  • Empower the community
  • Embrace open communications
Global transparency and visibility through collaboration and shared infrastructure
  • For all initiatives, track and publish status on a timely basis
  • Access to everything for everyone
Empathy, trust, humility, honesty and openness at all times
  • No one knows everything; as a team we know more
  • Learn from and share all experiences
Regular dogfooding of Visual Studio Application Lifecycle Management tools
  • Improve productivity of Ranger teams
  • Gather and share real-life experiences

Who are we?

We are a group of around 100 part-time volunteer engineers and 2 full-time Ranger PMs, scattered across the globe.

What do we do?

We are focused primarily on the delivery of out-of-band tooling and practical guidance to remove adoption blockers in real world environments. Typically a Ranger solution is a hybrid of practical guidance and supporting out-of-band tooling and sample code.image_thumb8

Why do we do it?

We do what we do, to help accelerate the adoption of Visual Studio ALM and DevOps. We gather actionable product feedback from real-world situations and customers and relay this to the Product Group, as well as identifying gaps in the product and filling them!Typically, the Rangers spend their personal hours to do the Rangers project work, and, not just anyone is invited to participate — Rangers need to be knowledgeable about Visual Studio, ALM, and DevOps, have the desire to strengthen the community, and contribute regularly.

Our history

The Rangers program began in March 2006 as a joint venture between the Visual Studio Team System team and the Worldwide Communities program, part of the Office of the CTO (Chief Technology Officer) in the Microsoft Services organization.

Frequently asked questions

How do I contact you?
  • Preferably, contact your favourite and regional Ranger from aka.ms/vsarIndex.
  • Alternatively contact us here (@almrangers).
How do I join the Rangers?
  • Please contact your regional Ranger and request him/her to submit your nomination on your behalf.
  • Submit the following information as part of your request:
    • Overview
      • Why do you want to join the Rangers?
      • Short and crisp bio, answering the common 5 index questions. See aka.ms/vsarIndex for examples.
      • Who are you?
      • What makes you “tick”?
      • Where you live?
      • Optional, if applicable
        • Why are you active in or with the Rangers program?
        • What is the best Rangers project you worked with and why?
    • 1-3min video of you with a quick intro, for example, covering answers above.
    • One or more non-IT (business) photo which includes you.
    • Contact details, including MSA (LiveID) account, contact email, postal address, and telephone number.
Renewing membership?
  • To remain an active Ranger you need to be actively involved in the Ranger community.
  • Renewals and special awards, such as distinguished or champion Rangers, are based on feedback from your peers.

Comments

  • Anonymous
    February 02, 2016
    I was hoping your site would have some guidance on best practices for work items in TFS ALM in general or in certain process templates, but I have not found any.  Do you know of any good articles, guides, or blog posts on this?  Mostly, I am looking for guidance on how to work with the TFS ALM paradigm instead of against it. I am formulating some notes for my company, with guidance such as "DO NOT nest work items of the same type--DO NOT create a hierarchy of work items of the same type.  DO change your work items' organization to fit the built-in hierarchy of TFS: Epic > Feature > User Story > Task. " Anything out there that can help us learn from other teams' experiences would be appreciated.

  • Anonymous
    February 02, 2016
    (continued from previous) please reply if you can to pszalapski@gmail.com.

  • Anonymous
    June 14, 2016
    Hi, is there a consolidated guidance for practices and tooling options for each stage of the ALM and SDLC from your collective experience? I'm looking for an example or starting point for a potential end to end setup as context to better understand the issues, considerations and challenges in getting this introduced and implemented in an organisation. With the popularity of DevOps and Agile methodologies (plus likely other methods I have not heard of) would likely influence this.

  • Anonymous
    September 19, 2016
    How I could know my regional ALM Ranger ? I live and work in San Francisco bay area.

  • Anonymous
    October 12, 2016
    How do I ask a question? (no twitter)Looked around the site and can't find any way to just ask something.(How to manage VSTS environment remotely using Powershell)

  • Anonymous
    January 25, 2017
    Hi guys, first of all THANKS, I'm a big fan of you and your work, the guidance about Branch & Merge was enlightening!Antefacto: We are going to change our approach to DLM and more specifically to the artifact packaging from a old style .NET projects with "_AssemblyRefernce" folder under TFS to a more modern .NET Core NuGet package reference for all the common libraries both internal and external.Disclaimer: I know we are a little bit in lat and also I know to two lines above describe our intention in a so confused manner, anyway I hope you get the spirit.Now we are wondering what's the best shape to give to our Repo, I mean the basic folder and subfolder:- how to deal with solutions and projects (one inside the others, at the same level in order to be able to refer the same project witihn many solutions)- folder src / lib / test as first level into the repo or within the solution as made by Visual Studio for some kind of project- how to deal with tests- ....and a lot of other considerations around the same topic.Is there somewhere an "ALM Ranger guidance" on how to organize the repo in order to better manage the projects oriented to NuGet packaging and using git?

    • Anonymous
      January 25, 2017
      MonDeveloper, if you search for Version Control (ex Branching and Merging) Guide on https://aka.ms/vsarsolutions, you'll find the latest version of the Dependency Management guide, which is dated, but will get you started. We're planning a new wave of articles around DevOps and Branching for https://aka.ms/techarticles, which we'll add to our catalogue. We're always interested to know what guidance is missing and which would be valuable to you.
      • Anonymous
        January 27, 2017
        @Willi-P, thanks!Not exactly, What I was looking for is a guidance on how to physically organize the repo in terms of folder structure, where to put solutions and projects, where to put tests and so on.And, since your work talk for you (it's really brilliant) I would love to have this kind of guidance specifically for different kind of projects, something like:- If you are developing a shared library (or a library set) your should organize this way- In case you are developing as Web Site this way- For a REST API this way- For a windows service or console application this wayI hope now it's more clear.Thanks in advance