Application Lifecycle Management Overview

As you may recall from Chapter 1, there are three main pillars of an ALM process:

• Traceability of relationships between artifacts: The lack of traceability can be a major cost driver in any enterprise. There must be a way of tracing the requirements all the way to delivered code and back again—through architect models, design models, build scripts, unit tests, test cases, and so on. Practices such as test-driven development and configuration management can help, and these can be automated and supported by TFS.

• Automation of high-level processes: There are approval processes to control handoffs between analysis and design. There are other handoffs among build, deployment, testing, and so on. Much of this is done manually in many projects, and ALM stresses the importance of automating these tasks for a more effective and less time-consuming process.

• Visibility into the progress of development efforts: Many managers and stakeholders have limited visibility into the progress of development projects. Their visibility often comes from steering group meetings during which the project manager goes over the current situation. Other interest groups such as project members may also have limited visibility of the whole project even though they are part of it. This often occurs because reporting is hard to do and can involve a lot of manual work. Daily status reports can quite simply take too much time and effort to produce, for example, especially when we have information in many repositories.

Other important topics that ALM addresses are as follows:

• Improving collaboration: Collaboration is needed between teams, team members, stakeholders, and users, just to mention a few relationships. When development is spread around the world in different locations, collaboration can be hard to manage without the help of a proper tool.

• Closing the gap between IT and business: The big gap between IT and the business side of an organization is a serious problem for organizations, preventing companies from delivering the greatest business value they can achieve in their projects.

• Using one tool: The complexity of using several tools for solving project issues as a team member can be tough and costly as well. Switching between tools can be a cost driver. Using one tool to add plug-ins and use more features directly in an ordinary GUI instead of switching between applications is preferable. So, if you have several roles in a project, you can still use one tool to get the job done.

• Enhancing role switching: ALM also addresses the potential to use one tool when switching among different roles in a project. In many cases, project members play several roles in projects. A developer, for instance, might also work with tests or databases. If that person can use the same GUI for all tasks, there will be minimal overhead for switching between these roles.

Team Foundation Server Overview

TFS has come a long way toward fulfilling the ALM vision, but it does not cover everything. TFS is an open and extensible product that will let you adjust its features to your needs and add the things it might lack at this point to support your specific needs. It is also important to know that Microsoft is spending a lot of time, energy, and money on developing this product further. It is not a toolset that will go away quickly (although one never knows); it is one of the most important toolsets in the Microsoft ecosystem.

TFS is now available in two versions; Team Foundation Server (TFS) and the cloud-based Visual Studio Team Services (VSTS). This book uses both versions for illustrations.

Team Foundation Server

You can see that the heart of ALM in the Visual Studio 2015 world is TFS 2015 or if you use the cloud-based version, Visual Studio Team Services (formerly known as Visual Studio Online), as shown in Figure 2-1.

Figure 2-1. An overview of Visual Studio 2015

TFS exposes different functions and services for developers, project managers, and others like version control, reporting, and build and work item tracking. Not shown in the image is that TFS uses Microsoft SQL Server as its data repository.

Note

Work items (Figure 2-2) are used to manage different types of information in TFS. We have work items for requirements, bugs, general tasks, and so on. To put it simply, a work item is a piece of work that must be completed in a project. The work item tracking system is one of the core parts of TFS for ALM process implementation.

Figure 2-2. The heart of TFS is the work item—in this case, a product backlog work item

Process Template

What keeps all of these services together is the process template (see Figure 2-3) that sits on top of TFS/VSTS. This is a very interesting part of TFS. The template helps you visualize and automate tasks and steps that the process includes. It helps you by providing document templates for requirements specs, test cases, scenarios, handoffs, and other artifacts you should produce.

Figure 2-3. The process template customizes TFS behavior

Most companies use some kind of process for their development or ALM. Even though some companies don’t think they have a process, they do. The process might not be written down, but the company still has ways of doing things that in reality is the process—for instance, naming conventions, where to store builds, how to handle change requests, and so on.

In many cases, we have seen companies with lots of money invested in their processes. They have sent staff to training, provided large process manuals, and so on. However, they’ve had problems getting project members to actually use the processes in their daily work. The excuses are many: the process is hard to understand, remembering all the process steps is difficult, the process is not automated or included in the tools, and many others.

The end result has been that project members use their own variant of the process, causing confusion during the project’s lifetime. This also causes severe problems, as handoffs between the development team and the operations team are often difficult. A typical bad scenario can occur when a system has to wait for deployment because the infrastructure isn’t in place for the new system. Operations was not involved (or perhaps even informed) during the project and suddenly they are expected to run the system on hardware they don’t have.

In TFS, you can implement your development process as a template that will be mandatory for all new projects. When you create a new project, you also create a new instance of the process template. You don’t have to stop at the development project level either. You can implement most parts of the ALM cycle in the template as well, enabling you to take advantage of TFS all along the way. The template helps you visualize and automate tasks and steps that the process includes. It helps you by providing document templates for requirements specs, test cases, scenarios, handoffs, and other artifacts you should produce.

The template also provides information about which reports you have available for each new project—reports that you’ll use to retrieve information about the status of projects and many other things. The template also contains information about one of the most important core parts of TFS: the work items. These can be adjusted as needed so you can make sure they contain the information the organization must have included with them. This information could be status information for a bug, for instance, such as Active, Resolved, or Closed.

This template is so flexible that you can develop and implement your own process, you can choose to use any of the three that Microsoft supplies, you can use a third-party template, or you can choose to customize the Microsoft templates to your own liking. You can also have several process templates in TFS so you can use different templates for different projects. Because TFS is not used to its full potential without the process templates, we cannot stress enough that you should consider which templates you want to use and the information you want them to include.

TFS Web

All projects in TFS have their own web sites available. By using Windows SharePoint Services or Server, a team project portal is created when the project itself is created. By using this portal, or the more advanced Team System Web Access, you can access most of the functionality in TFS. The project portal lets you access the parts of TFS that are available from inside Visual Studio, from an easy-to-use interface, especially for non-technical project members. Figure 2-4 shows what Web Access could look like.

Figure 2-4. The Team System Web Access start page on TFS

Many of our customers use a team project portal primarily to provide access to reports and work items for non-technical people not used to the Visual Studio interface. When we want to give an external user (such as a customer or remote stakeholder) access to work item creation and editing, or another more advanced task, we typically use Web Access.

Traceability

Having traceability in your ALM processes is key to the successful delivery and maintenance of applications and systems. I once visited a company that stopped making changes to its systems just because no one ever knew where a change (or bug fix) might have its impact. You don’t have to live with such a situation.

These TFS features can help you with traceability so you can avoid such problems:

• Work item tracking

• Test-driven development/unit testing

• Automated builds/continuous delivery

• Check-in policies

• Version-control system

Let’s look at some of the specifics involved with these features, starting with how the work item tracking system implements traceability.

The TFS Work Item Tracking System

Sometimes it seems like we have tons of Post-its on our monitors and desks—each one containing at least one task we are supposed to take care of. We would like to track them in a tool that could help us, but often it just isn’t possible. It could be that some tasks are connected with one project, others with another. We have tried writing them all down in an Excel spreadsheet and saving that to the computer. But soon we find that this spreadsheet is located on our laptops, our customer’s computer, our desktops, another customer computer, and so on. And we have no idea which one is the current version.

The same thing often occurs in projects. Project managers have their to-do lists for a project, and they all have their own way of keeping them updated. Let’s say a project manager (PM) uses Excel to keep track of these tasks—the status of tasks, to whom they are assigned, and so on. How can the PM keep the team updated with the latest to-do list? If the PM chooses to e-mail it, chances are that some people won’t save the new version to disk or will just miss it in the endless stream of e-mail coming into their mailboxes. Soon there are various versions floating around, and things are generally a mess.

Work Items

TFS has a task-tracking system at your service. We will take a closer look at work items in Chapter 4, so we will keep it brief here. The core of this system is represented by the tasks themselves, which as we said earlier are called work items. A work item can be pretty much what you want it to be. It can be a bug, a requirement of some sort, a general to-do item, and so on. Each work item has a unique ID that helps you keep track of the places it is referenced (see Figure 2-5). The work item ID (60 in Figure 2-5) lets you follow a work item, let’s say a requirement, from its creation to its implementation as a piece of executable software (component).

Figure 2-5. Each work item has a unique ID, in this case Product Backlog Item 60

Work items provide a great way for you to simplify task management in a project while at the same time enabling traceability. No more is there confusion as to which version of the task list is the current one; no more manual labor for gathering status reports on work progress that are used only at steering group meetings. Now you have a solution that lets you collaborate more easily with your teams and enables all members and stakeholders to view status reports whenever they want. You can also more easily collaborate with people outside the project group by adding work items via the web client.

TFS is so flexible in this regard that it lets you tailor the work items as you want them to be. The work item tracking system is one of the core components of TFS. This system enables you to create work items, or units of work, and can be used to enable traceability. You can use the work items included with TFS from the beginning, or you can choose to adjust these to your needs, or even create your own work item types. Each work item instance has a unique ID that you can attach to the things you do in TFS. This enables you to follow one work item—let’s say a requirement, for example—from its creation to its implementation as a piece of executable software (component). You can also associate one work item with others and build a hierarchy of work items.

The work items can contain information in different fields that define the data to be stored in the work item. This means that each field will have a name and a data type.

All work items can have different information attached to them. You can have information about to whom the work item is assigned and the status of the work at the moment (for example, a bug could be open, closed, under investigation, resolved, and so on). The State field can be modified so that each work item type can have its own state mechanism. This is logical because a bug probably goes through states different from those that a general task goes through, for instance. You can also attach documents to the work item and link one work item to other work items. You can even create a hierarchy of work items if you want. Let’s say that you implement a requirement as a work item and that this requirement contains many smaller tasks. Then you can have the requirement itself at the top and nest the other requirements below that so you know which work items belong to which requirement.

When a bug is discovered, for instance, you can quickly follow the original requirement by its work item ID and see in which places in the code you might have to make some fixes. You can also see the associated work items so that you can evaluate whether other parts of the code need to be changed as a result of this bug fix.

TFS saves information about the work item on the data tier, which helps you follow the change history of the work item. You can see who created it, who resolved it, who closed it, and so on. The information in the databases can be used for display on reports, allowing you to tailor these depending on your needs. One report could show the status of all bugs, for instance. Stakeholders can see how many open bugs exist, how many are resolved, and much, much more. It is completely up to you and your organization how you choose to use the work items.

If you implement a requirement as a work item, you can use the work item ID to track this requirement through source code and to the final build of the executable system. By requiring all developers to add one or more work item IDs to the check-in using a check-in policy, you can enable this traceability.

Configuration Management Using TFS

In any (development) organization, you need to have control of the versions of your systems you have in production. If you don’t have that, the overall ALM process will suffer, because you will suddenly lose traceability. This will make it harder to implement changes and bug fixes, because you won’t know which versions you need to update.

Without the help of a proper tool, you soon will get lost in the variety of applications you have. TFS can help you with this in many ways. After a brief description of software configuration management, I will cover three of the most important concepts that have great support in TFS and Visual Studio tools:

• Version control

• Release management

• Build management

Note

In software engineering, software configuration management (SCM) is the task of tracking and controlling changes in the software. Configuration management practices include revision control and the establishment of baselines and are very important. There are several goals of SCM, including the following:

• Configuration identification: Ensuring that you know what code you are working with

• Configuration control: Controlling the release of a product and its changes (version control)

• Build management: Managing the process and tools used for builds

• Defect tracking: Making sure every defect has traceability back to the source

If these issues are not covered by your ALM process, you could very soon find yourself in a troublesome situation. It is crucial for the development teams to have full control over which versions of the applications exist, which are in production, and where. This topic is closely related to the portfolio management team, and generally a big company has one or more persons devoted to keeping track of this.

Version Control and Release Management in TFS 2015

Using the version-control system in TFS, you can manage and control multiple revisions of the same information in your projects. This information can be source code, documents, work items, and other important information that you want to add version control to. When you want to work on an item under source control, you check it out to your local computer so you can start working on it. When work is done and tested, you check in your changes so the version on the server is updated.

The version-control features of Team Foundation Server 2015 are powerful. They are fully integrated into the GUI, which is something that ALM prescribes as well. If you want to, you can access some of the features from a project portal as well. Many people want to use the command line for their work, and TFS enables them to use the command line for working with version control as well.

However, if you do want to use Visual Studio to access the TFS version-control system, you can do that. The extensibility of TFS makes this possible. One example of this is the Team Explorer Everywhere suite of client applications that can access TFS, including the version-control system. Teamprise has developed an Eclipse plug-in that lets users access TFS from Eclipse instead. Teamprise also lets you access TFS from Mac OS X and Linux command lines. This way, you can more easily integrate different development platforms in a TFS project. You still will use the TFS repository and have the ability to get reports and other information directly from TFS.

Build Management

A build is basically the process of taking the source code and all other items necessary in an application and building it into executable software. Team Foundation Build is the build engine in TFS and executes the build process as defined by the TFS settings. Team Foundation Build is built on the Microsoft build engine (MSBuild), which is the build platform for Microsoft and Visual Studio. You can attach unit tests to a build process so that you automatically run these every time the build process kicks off. Team Foundation Build is fully integrated into the Visual Studio GUI so you don’t have to use separate tools for handling these tasks.

Team Foundation Build supports several types of builds:

• Full builds: You build everything in the project. This can be resource- and time-consuming.

• Partial builds: You build only one or more parts of the system.

• Nightly builds: Many projects build the system during nighttime. Especially if the build process takes a long time, this can be very handy.

• Custom builds: You can use the extensibility of TFS to create your own build types or edit any of the existing ones.

• Incremental builds: You build only the components that have been changed since the last build.

You can also add a number of tasks that you want to be executed when running the build:

• Get the latest source code from the version-control system

• Compile sources

• Perform architectural validation

• Run static analysis tool

• Execute unit tests

• Update work items

• Perform code coverage

• Calculate code churn (how many rows of code have been modified or added since the last count)

• Produce build reports

• Drop exe/output into predefined location

Automation of High-Level Processes

Without one or more templates, TFS will not be used to its full potential, as you saw earlier in this chapter. You could still use its version-control system and some other tools, but the real value comes from using it to automate your ALM process. In the process template, your whole ALM process is defined. Chapters 5 and 6 cover a lot more on this topic as well.

The template defines the following:

• Work item types: Which work item types are necessary and what information they should have attached to them. You can also define the workflow for a work item. For a bug, you might have different states the item flows through, such as Active, Resolved, Closed, and so on.

• Project phases: By using areas and iterations, you can define the initial project phase setup of your projects. If you use RUP ( https://en.wikipedia.org/wiki/Rational_Unified_Process ), you can define the process phases in that model, or you can create the first sprints of a Scrum project. Areas and iterations are flexible, and you can create your own way of working through these concepts.

• Document structure and templates: The number of documents that should be produced during a project will differ depending on your process model. In the process template, you define the document structure you need and the templates you should use. For instance, you can add templates for requirement specifications or acceptance testing here.

• Reports and queries: In the process template, you can specify which reports and work item queries you need to have as defaults in your projects. You probably want reports and queries showing the progress of your project, such as the status of bugs or work remaining. You can create your own reports by using SQL Server Reporting Services or Excel and add them to all projects by adjusting the process template.

• Security: The template also adds information about which users or user groups have access to what information. You can connect TFS groups to your Active Directory accounts, for instance.

The process template is the overall process for your ALM implementation. Many of our customers create different templates for different kinds of projects. They also create templates for operations, so that when a development project is finished and deployed, the operations staff can use their template to run the system until the system dies. A few customers have started creating a template for Information Technology Infrastructure Library (ITIL), for instance, and we are looking forward to seeing the result of that work.

It is important to remember that you can adjust the process to your needs. You should consider changing the default templates or even replacing them, rather than adjusting your own way of working to the templates that come with TFS out of the box. Microsoft enables this flexibility by letting you easily access the process templates to adjust them or to add new templates.

Visibility

Information about project status is important to all participants of a project—and we don’t mean team members only, but stakeholders and decision makers as well. As project managers, we have spent too much time chasing down information to answer questions about the status of projects, how much work remains, and what the latest bug status is.

TFS provides two primary ways of enabling visibility:

• Reports: Reports are created by using SQL Server Reporting Services (for more information, check out Pro SQL Server 2012 Reporting Services, 3rd Edition, by Apress) and accessing the TFS data tier directly. You can define and adjust these as you want. You can also use Excel to create reports if you prefer.

• Queries: Queries are used to ask questions of the work item tracking service. One question might be how many bug work items you have. How many and which are dedicated to me? How many bugs are there? And so on. You can create new queries when necessary.

By using these two components, it will be easier to gather the information you need for your status reports for a steering group meeting or project meeting. You won’t have to look around in several places and in several applications for this information anymore; instead, you can use the automated reports and queries from inside TFS.

Project owners, project managers, and Scrum masters will certainly benefit from TFS. Because TFS has all data in the same repository, you can more easily retrieve the correct information when you want it. The flexibility of the SQL Server database that stores all information is great. You can work with the data warehouse information just as you would with any other database.

By using the project portal or TFS Web (see Figure 2-6), you can publish information (in the form of custom-built controls that users cannot change at this time) so that everybody who has privileges can see them. This is an easy way to make sure that information is available all the time. Just this little, relatively non-technical improvement will off-load work from the project manager, freeing some of the PM’s or PO’s time for better things.

Figure 2-6. Viewing reports from TFS Web

Collaboration

As you know, TFS comes with Team Explorer, which is an add-on to Visual Studio. With this tool, the developer can access every aspect of a TFS project. The developer can view reports and queries , for instance, as well as access the document in the project. The developer can access the version control system as well as build systems, tests, and so on.

The Team Explorer is full featured but is still a tool for people used to working in Visual Studio. For us that is no problem, but for most project managers and stakeholders, the GUI is confusing. They want to have an easier-to-use tool to access the relevant information.

Each project that is created with TFS has a project portal created as well. This portal provides access to reports, documents, project process guidance, and other project-related information through a web interface. This enables people who are not used to the Visual Studio interface to easily retrieve the information they need.

There is also a collaboration site called team room(see Figure 2-7) that is created for each TFS Team Project. This is a collaboration area where team members can chat, share information, and let TFS display information about different status aspects (such as how the nightly build went).

Figure 2-7. The TFS team room

Collaboration, of course, does not only mean giving access to information, even though this is as important as any other means of collaboration. Collaboration also means that you should be able to work together to fulfill one or more goals.

Work Items for Collaboration

You can use the work item features of TFS to enable your process workflows. Let’s say a project manager, or anybody responsible for inputting requirements as work items into TFS, creates a new work item of the Scenario type. This scenario should probably be assigned to a developer to implement. The project manager uses the work item system to assign (see Figure 2-8) the scenario to a specific developer, in this case Joachim. Joachim continues to work on the scenario until it is ready for testing. He then assigns the work item to a tester who performs the testing. When the testing is done, the work item is perhaps closed. If a bug is found, either the tester or anyone finding the bug can use the work item tracking system to see who developed the scenario implementation and reassign it to that developer, in this case, Joachim again. TFS keeps track of who has worked on the work item so that you don’t have to manually keep track of this.

Figure 2-8. Assigning work items to a specific person

Use of One Role-Based Tool

A good ALM tool should enable you to use add-ons that will provide new features inside one interface. If a developer needs testing features, you should be able to integrate them into the development tool. The developer should not have to switch tools to do testing tasks. This is also what Visual Studio offers. There is no context switching as team members can use the same GUI no matter what role they are performing at the moment. TFS is also extensible and lets you create your own add-ons as well as purchase third-party add-ons that will be accessible from inside of TFS.

Extensibility

When the built-in features of TFS are not enough, you can use the extensibility features to expand and enhance it. TFS is often seen as a closed black box that Microsoft ships, when it’s more like an enterprise resource planning (ERP) system for ALM. Any ALM environment must be customized for an organization’s processes and the existing applications and services.

Many of our customers have been a bit reluctant to customize TFS. They have instead tried to squeeze their way of working into the templates Microsoft provides with TFS. We think this is the wrong way to do it. Our suggestion is that you start the other way around. Start by asking yourself how your organization wants to work. This process involves all parts of the organization, from the business side to operations. Try to find agreement on how to work in the ALM process. By doing so, you will see that this also is a good start for collaboration in the company.

For instance, consider the work items and the information in them. If the fields and information in the MSF templates are not enough, extend or edit them. TFS lets you do this by changing the process template. You can choose to add the information that you need, and it will be stored in the TFS databases, so you can have access to it from within your reports and queries. Don’t forget to change the reports or queries, as well; otherwise, you will not see your information.

Some of our customers have changed the workflow of a work item by adding more states to it, when the ones supplied have not been enough. Often we have used the TFS Power Tools to do this.

When you have an initial idea of how you want to conduct the ALM process, start looking into what TFS gives you out of the box. Use what can be used, change other things, and build your own solution where needed.

One great strength of TFS is its extensibility and flexibility. You can adjust the whole tool to fit most parts of your ALM process. If you want to, you can develop your own add-ons by giving support to roles not included from the start. We strongly encourage you to use these extensibility features, but in the end it is your choice.

Extensibility is a great way to integrate existing systems and potentially migrate some of them into TFS in order to reduce the toolset in the organization.

Differences Between TFS and VSTS

VSTS is cloud-based. This is also the version of Team Foundation Server where Microsoft deploys all new features first. Every three weeks Microsoft aims to update VSTS. These updates are then packaged to a TFS update that is released approximately every three months. Table 2-1 shows an overview of the difference in features between TFS and VSTS.

Keep in mind that the information in Table 2-1 will change as time goes by. VSTS is updated every three weeks with new functionality and the differences between the two will probably diminish.

Summary

In our opinion, Team Foundation Server can help you implement a good, automated, and robust ALM process. There are features for all aspects of ALM. Correctly used, these features will help you improve your ALM process, which in the end will give you better business value and more successful projects.

The three pillars of ALM—traceability, process automation, and visibility—are all important for any organization to have. TFS is a great foundation on which to build ALM solutions. TFS has work item tracking for traceability, process template implementation in the tool itself for process automation, and reports and queries for visibility. Through a project portal, accessible via the Internet, you can improve collaboration among all parties having an interest in your projects.

TFS is role based in the sense that it supports different development roles. It has support for architects, developers, DBAs, testers, and more. They are not separate tools either, but they are all accessible from a unified GUI. You can also add custom add-ons to the GUI and do not have to use several tools to get the job done.

Product owners and project managers have the capability to use tools they are already familiar with. Most use Excel or Project for project planning, and there is integration between these tools and TFS. You can easily sync information among these tools.

The extensibility of TFS makes it fairly easy to write your own code integrating TFS with other applications. This is an incredible strength of TFS, and something we should give Microsoft credit for.

So, all in all, Team Foundation Server is a great foundation on which to build your Application Lifecycle Management process.