Why TFS/VSTS for DevOps Practices||||why-tfs-ideal-for-devops-practices

Why TFS/VSTS is Ideal for DevOps Practices

Why TFS/VSTS for DevOps Practices||||why-tfs-ideal-for-devops-practices
Share on facebook
Share on twitter
Share on linkedin
Share on email

DevOps is essential for any organization, large or small, that wants to succeed in an increasingly competitive marketplace. Customers now expect the latest, greatest and fastest software at the drop of a dime, and DevOps—the proven, people-focused practices and processes for building, testing and releasing software faster and more reliably—is an organization’s best bet to keep up with these demands.

Implementing a DevOps culture requires intentional change. You need to not only plan and prepare your organization to eliminate siloes and empower employees, but also consider tooling as a piece of this cultural change. The best tool for the job? Team Foundation Server (TFS)/Visual Studio Team Services (VSTS).

Assuming your company has started with People, Process then Practices, or is using Gene Kim’s “Three Ways,” let’s talk tooling and why VSTS has almost everything you need to amplify your DevOps practices.


VSTS for Continuous Integration (CI)

Using the build module, VSTS users can easily create their own CI, allowing teams to integrate code with quality.  VSTS also offers many different methods of source control (Git, GitHub, TFVCS and more), so you can create CI builds from your selected source control repository.  If your team likes a distributed source control model, Git or GitHub are for you; on the other hand, TFVCS is a best for teams that prefer a more centralized model. For instance: Let’s say I create a backend Git repository in VSTS named “eric_backend_utilities.”  Using that repository, I can then create a CI build definition named “eric_backend_utilities_CI” that compiles code and runs the teams automated unit tests.  This typical CI pattern ensures that when you commit code to your repository, it cleanly passes all your initial quality measures, leaving that repository in a known state.

You can also use VSTS to build .NET, JavaScript Android, Xcode and Java applications.  These can be built on Windows, or Linux agents depending on your preference, but we have found that some builds—like ones that use npm packaging—may run faster on a Linux agent.



VSTS for Continuous Delivery (CD)

With VSTS, you can use the build module for CD in conjunction with the Release Manage (RM) module to automate the building, testing and deployment of your app. Your CD build allows you to package up your application’s code so you only have to build once—but using the release pipeline from RM, it allows you to automate deployments across multiple environments.

Pre-approvals by designated people, or groups of people, allow you to have the owners of each environment accept or reject the application when they want it.  Approval gates also allow your release to validate against certain conditions.  For example, you can set up automation to validate that no severity 1 or 2 defects are open against the work items contained in the deployment.

You can also deploy any Infrastructure as Code in your release to keep your environments in sync.  This can be done as a separate release or integrated with your release pipeline, ensuring that your environments are the version your application expects.


VSTS for Feedback Loops (Monitoring and Telemetry)

VSTS offers the ability to deploy and display your monitoring and/or telemetry using customizable dashboards.  Your team can create visual displays of metrics that are important for your team.  Metrics like outstanding bugs, successful builds and deployments, code quality are examples of different pieces you can add to your dashboard.

Tools such as Application Insights, New Relic or other monitoring tools have widgets that can be placed on a dashboard, which you can then project onto large monitors, so your team can actively monitor your current application health.

Also, the Product Backlog in VSTS allows Product Owners to take feedback from actual customers and use their input to refine their backlog.  Product Owners can then work with their teams to implement new features that customers express interest in.


VSTS for Infrastructure as Code (IaC)

Whatever tool you use to set up environments, you can use VSTS to manage the source code.  This may be set up as a different repository within your application, or as part of each repository that needs environment setup.  The decision on which repository to place your IaC depends on your architecture, but the principles all are the same.  For instance: If you are using ARM templates to update and setup environments in Azure, store the PowerShell and JSON files in your source code.  Afterward, set up a CI build along with tests to validate the code that creates and updates your environments–then you can set up your infrastructure creation or update in your release pipeline.

Setting up your Infrastructure in code helps your team keep environments in sync with application code.  You can also tie your infrastructure to application via versioning, enabling you to roll back applications easily when necessary.  Other benefits to IaC include enabling a full cycle development team and standing up environments quickly.


Additional Benefits of Using VSTS for DevOps tooling

In addition to the current features, VSTS also provides frequent updates (every 3 weeks) with new features.  Also, the VSTS team follows best-in-class DevOps and agile principles, so you can rest assured that using the tool will allow you to build a solid DevOps culture and deliver more value, more frequently.

Want to learn how to use VSTS for your DevOps tool across the development lifecycle? Try it for free or contact us to learn more about DevOps and proper tooling.


Stay Up-To-Date