Application Lifecycle Management: an introduction for SharePoint people – part 1
Note: this article was originally published in the DIWUG eMagazine, issue #9
Application lifecycle management describes the way an application is managed from its conception, through deployment and operation, to its inevitable retirement. Whether you are a single developer or a member of a larger team, managing an applications lifecycle can be challenging. To help architects, developers and engineers with these tasks, Microsoft created a set of tools and it is part of the Visual Studio product lineup. But first, let’s start with Microsoft’s definition of Application Lifecycle Management (straight from the Visual Studio ALM Product Info):
“Application Lifecycle Management (ALM) is a continuous process of managing the life of an application through governance, development and maintenance. ALM is the marriage of business management to software engineering made possible by tools that facilitate and integrate requirements management, architecture, coding, testing, tracking, and release management.”
In this and follow up posts I will touch the highlighted areas: continuous process, the tools and parts of the integrated features. By “continuous process” we acknowledge, that ALM is not a one-time implementation. It is not “fire and forget”, but instead a process aimed at continuously improving our applications life. This process is supported by an integrated set of tools: Microsoft Visual Studio Team Foundation Server (or TFS for short), currently at version 2012.
Team Foundation Server is not the only product playing a part in ALM, there are other products too (like Microsoft Test Manager and of course the Visual Studio IDE itself). Just remember to see it like this: Application Lifecycle Management is not Team Foundation Server. And Team Foundation Server is not Application Lifecycle Management. TFS is part of a set of tools Microsoft provides for supporting your ALM efforts.
“Everybody listens to WII FM”
“Everybody listens to WII FM”. For those of you who don’t know what this quote means, well, WII FM is not a famous radio station but stands for “What’s In It For Me”. You, as a SharePoint developer or software architect, probably already have a pretty busy schedule these days. I wouldn’t be able to persuade you to install a new tool, invest time to get to know it fairly well and adjust your current developer workflow without at least trying to make clear what the benefits for you could be!
The product lifecycle
A typical product lifecycle starts with the realization of the product, its conception. You or your sales team takes the product to market and you will start selling copies. Over time sales hopefully picks up and the revenue increases. You release some minor updates, patches or maybe even a new version, but inevitably your product will reach its end of life. Sales will drop and the product will retire.
Figure 1: a typical product lifecycle, courtesy http://osnabrugge.wordpress.com/
Obviously you would like to gain as much revenue from your development efforts as possible and to be able to do that, you will need a good product first. Application Lifecycle Management can help achieve this goal by supporting you in the following main areas:
The functionality in Team Foundation Server includes the following related features:
Project management: manage your entire application project. This includes general project metadata, its files (both source code and related documents) and things such as authorization. It also helps with planning issues such as tracking remaining work, open bugs, available resources, etc.
Process templates: guidance in the form of Visual Studio xml templates describing how you would like to work with your solution. Out of the box, Microsoft provides several (3) default templates with Microsoft Visual Studio Scrum being the most popular one. And you can modify or add your own templates if the default ones don’t work out for you.
Work Item Tracking: work items are a first class citizen in TFS. The types you will use depend partly on the process template chosen, but you will find things like Product Backlog Items, Requirements, Bugs, Impediments, Test Cases and more. They can contain metadata such as a description, state, priority, assignment and so on.
Figure 2: a TFS work item, in this case a Bug
Reporting: one of the key features of Team Foundation Server. You can build almost any view or report on TFS repository data to quickly get the metrics and insights you’re looking for.
The benefits of adopting ALM, a modern application lifecycle and using Visual Studio and Team Foundation Server:
- Collaboration. You and your team members connect to a local or cloud based TFS server using Visual Studio (other IDEs supported too) and all work with accurate and current project data and source code.
- Process Guidance. You and your team members use a process template to set up the project structure. You used to manage the product backlog in Excel, but now you can set up a backlog in TFS and manage it directly from within the Visual Studio IDE.
- Reporting. On track? Need Scrum (Burndown) charts to monitor a team’s progress or estimation of remaining work? Integrated reporting available directly in the Visual Studio IDE gets you the information you need.
- Quality Assurance. Branching and merging ensures you will not develop on your “Release” branch and only merge the code (or features) that are ready to be released. Central builds (or team builds) ensure consistent builds, proper versioning and traceable software. Automated Unit Tests can be part of every build, so you can make sure the new functionality “doesn’t break stuff”.
As you start playing with the tools you will most likely discover other significant benefits.
Unlike developers in most other areas (Windows Form, Web) SharePoint developers are not particularly well known for their application lifecycle management efforts.
- Source control and versioning is done through a folder structure, sometimes even on the Windows Desktop!
- Local builds are released to production/ customers
- No software branching
- Zero automated testing
- Requirements gathering in Excel
- Email is used for collaboration on a project
Tools like Team Foundation Server target most of these mistakes and pitfalls with features right from within the Visual Studio IDE.
Apps for SharePoint
Modern applications need a modern lifecycle. Back in the day development teams often had a typical approach when creating SharePoint solutions. First they would start with requirements gathering. Mockups, wireframes, functional designs, the works. Depending on the scale of the solution they would go in hiding for days, weeks, months working on the realization of the product. After extensive testing the product was released to the customer. During its product life you would release minor updates, bug fixes and maybe even a V-next. Creating apps for SharePoint (or Office), especially those targeted at the Online Store, require a different approach. Requirements gathering is done through feedback and feature requests. Based on that feedback, you will want to release and deliver quickly and frequently. Your biggest concern now are bad reviews and low ratings!
Apps for SharePoint 2013 benefit greatly from this continues improvement and a modern manageable application lifecycle.
In a follow up post, I will show you how to get your hands dirty and setup a TFS environment for your SharePoint projects!