Managing the Application Lifecycle
by Simon Bisson
Can Visual Studio 2017 help you get started with Application Lifecycle Management?
HardCopy Issue: 71 | Published: May 10, 2017
The way we build applications is changing, and the tools we’re using are changing to fit in with and take advantage of these new ways of working. So it’s not surprising to see Visual Studio 2017, and tools from its partners, taking on these new application lifecycle management concepts and building them into the tools on our desktop and into the cloud services they use.
Tim Sneath, Principal Program Manager for Visual Studio at Microsoft described much of this as “moving things left” in the development stack. That’s a term we’ve heard a lot from devops folk as it describes a process of automated testing and deployment, and of blending features from one part of the development process with another. You can see some of this in Visual Studio 2017 where, thanks to the Roslyn compiler-as-a-service features of
.NET, unit tests can be run on your code as you write it, and where code coverage analysis is just another feature of the IDE.
Bringing features like this into Visual Studio make a lot of sense, especially as Roslyn is now the default .NET compiler, and works not just with the familiar .NET languages but with Xamarin and Unity, and with the new cross-platform .NET Core. Development today is about a lot more than simply churning out thousands of lines of code.
Part of this change is a shift away from the familiar Software Development Lifecycle (SDLC), which was focused purely on the process of building code, to a much broader Application Lifecycle Management (ALM) approach. Instead of tracking development from requirements gathering to deployment, ALM goes a lot further, wrapping the entire life of a project from initial concept to eventual decommissioning, and encompassing several passes through the old SDLC model. While ALM doesn’t explicitly support devops, it is able to bring in inputs from operations to the development team; and it can be seen as the tooling that is required to deliver the dev in devops.
One of the key features of a well-designed ALM solution is the ability to pick and choose the tools you use as part of your delivery and management platform, thanks to APIs that offer simple integration points. That way you can use Visual Studio as a code editor, GitHub Enterprise as a repository and collaboration platform, Chef for configuration management, Jenkins for integration and as a build pipeline, HockeyApp for device testing, and any of a wide selection of monitoring tools to see what happens once your code’s been deployed.
Microsoft’s ALM platform
Microsoft’s own Team Foundation Server (TFS) 2017 is a big part of its Visual Studio-based ALM tooling. Whether it’s on-premises or in the cloud as Visual Studio Team Services (VSTS), it is a powerful continuous integration tool. You can’t really deliver on the promise of ALM without automation, and having a continuous integration tool as the backbone of your delivery pipeline is key to managing and implementing automated build, test, and deployment.
While TFS is the obvious choice for Microsoft-centric continuous integration, cross-platform and containerised delivery do have other options, with both Jenkins and Travis CI proving popular. VSTS is another option, especially if you’re targeting Azure, either as a platform or using virtual machines (VMs) and containers.
The latest release of TFS Server is a hefty piece of code, designed to run on 64-bit versions of Windows Server alongside SQL Server. While it’s usually installed on a standalone server, it can also be virtualised, so you can run it as part of a private or hybrid cloud. Once installed it offers browser access to your codebase, or connects directly into developers’ copies of Visual Studio.
A key feature of TFS 2017 is a powerful code search tool that can operate across multiple code repositories, helping you look for sections of code across projects. There’s also the option to search for work items which allows you to see whether developers are working on the code they’ve been assigned.
TFS work management tools are an important feature as they let you run an agile development process using the server to manage priorities with Kanban-like boards that let you see current and planned features, and monitor burndown as new features are completed. This approach gives you visibility on your application backlog, allowing you to plan development sprints and future releases.
TFS also offers the option of hosting NuGet packages in your own server, rather than relying on third-party services or setting up and managing a separate server. Having your own package server gives you control over what packages developers can use in their code, ensuring only trusted and tested code runs and ensuring that your build process won’t add new code you weren’t expecting – an important part of any ALM continuous integration process.
One advantage of using ALM tooling is its ability to support different services. If you’re using TFS you can use its built-in source control tools, or work with alternative approaches, and their associate methodologies. That means you can quickly plug-in GitHub (either a locally installed Enterprise edition or the new cloud-hosted Business service) to take advantage of the popular gitflow branching approach to source control. With approaches like gitflow, instead of one main source tree you have many, creating new branches for new code, and using pull requests to bring tested code into bugfix, release and main. TFS does support its own Git implementation, but using an alternative service can give you access to more features.
Working with TFS you can see formatted pull requests in your email, and hop quickly to the code using an in-browser file viewer that not only lets you see the code itself, but also commit comments from the developers on your team. Not only can you see the code that’s changed, but you can also see what your developers have said about what they’ve done, giving you the opportunity to collaborate more closely as new features are added and bugs squashed.
One important feature to look for in any ALM tooling is support for Markdown formatting. As developers can be using anything from Vi and Emacs to Visual Studio or Eclipse, you’re going to need a common formatting language for comments and commit statements around code. Markdown’s simple formatting directives can be used in any editor, and then displayed in the browser. Another increasingly popular feature is emoji support. Emoji has become a convenient shorthand in collaboration, and it’s often easier and quicker to send a thumbs-up or thumbs-down.
Microsoft’s new TFS build tooling is a much-needed improvement. You can jump straight from a build log to the code that caused an error, saving time in interpreting log data and mapping it to a specific file and a specific line. There’s also support for stepping outside the traditional Windows build model into the Java world with tooling for working with common Java build environments like Maven and Gradle, as well as delivering iOS and Android builds from Xamarin.
Enterprise and cloud apps now also get support for containers, with Docker support using Windows Containers as a build target for your code. TFS takes that Docker support a step further, allowing you to deliver code to a Docker Hub instance and then manage deployment to Docker hosts ready for use.
Using containers as a continuous integration endpoint makes sense, as you can use code to define the networks they operate on and the features that the containers need. Once you have defined your containers, deploying a complete application is simply a matter of choosing the right options in your environment settings. Both .NET Core and ASP.NET Core run on Linux so you’re not limited to Windows containers and hosts. The release management tooling in TFS 2017 will deliver your code to the appropriate environment, ready to run, whether it’s a binary, a container, or a web app – or even a set of Azure Resource Manager descriptions.
Continuous integration has rapidly become a key development methodology, and is vital to the successful delivery of any ALM platform. Code needs to be tested, built, and deployed in an automated fashion. That might mean automatic deployment to app stores or code repositories once tests have been passed, or in many cases the complete deployment of an entire virtual architecture. Support for technologies like containers means that it’s now much easier to consider a complete environment as a build target, rather than selectively deploying elements of an application.
It seems counter-intuitive to consider an entire network of servers and applications as the deliverable at the end of a build, but it makes a lot of sense: instead of considering an environment as something that’s flexible, it needs to be considered as an important entity in its own right. Any change needs to be proved in test and handled by change and configuration management tooling before being deployed, with the option of a quick roll-back to an earlier known good state if necessary. Many application failures result from configuration changes that haven’t been properly tested, so removing this element of risk can help reduce downtime.
ALM has a much bigger view of what an application is than you might initially think. Any application is the sum of its dependencies, including the services and APIs it uses. They’re all factors that need to be considered at all points during development and through the life of your code, especially if you’re relying on third party APIs or cloud platforms that are updated on their own continuous integration trajectories.
That’s why having an ALM solution is important, and why Visual Studio 2017 and TFS work well together as a foundation that’s flexible and extensible. Microsoft’s history of openness around the Visual Studio platform gives it an advantage as it’s already got an ecosystem of developer tool partners with software that addresses many key developer issues. If the ALM feature you want isn’t in Visual Studio or TFS, then you can probably find it from a partner, or even build it for yourself.
Plugging a third-party tool into Visual Studio 2017 makes a lot of sense. Its built-in Marketplace gives you quick access to a wide selection of both trial versions and full tools that add many new ALM-related features to your IDE.
One advantage of a tool like ReSharper is its support for both code suggestions and hints, which can guide developers in the direction of writing better code. These are generated not when there are errors, but when the tooling detects that code could be improved, perhaps to make it more flexible, or more extensible in the future. Having a software-based pair programmer in your IDE is a surprisingly useful tool, especially when working in a distributed team where code review becomes a complex process. ReSharper’s library of fixes also help, giving you tools to correct your code, and letting you pick an appropriate solution.
As well as in-line code inspection, ReSharper can work across an entire project, identifying code that might be redundant. Architects can go beyond the built-in inspection tools to add their own rules, making it easier to handle new APIs and applying coding standards so that the code becomes easier to maintain and easier to migrate to a new version. Similarly, you can use the various refactoring tools to refine your code, for example turning classes into interfaces (or vice versa) as well as handling method calls and managing strings for localisation.
ReSharper’s legacy as a tool for handling
.NET refactoring makes it a powerful tool for managing how your code changes, working quickly across an entire solution and not just a single file. Refactoring can also cross language boundaries, so if you change a property name in an XAML file, those changes can reflect back into the underlying C# code.
JetBrains offers a large family of .NET tooling, which don’t only work with individual copies of Visual Studio but can become part of an overall approach to code hygiene. By mixing code editor enhancements with profilers and test tooling, working alongside TFS, you can give your developers the IDE they need to interact with much of the tooling necessary for an ALM implementation.
ALM is about a lot more than just the development process. It starts with effective requirements capture and design prototyping. Tools like Infragistics Indigo Studio work here to capture user stories and map them to design prototypes that can then be used to define the APIs and data needed to deliver an application. The same tool can wrap the entire design and development process, getting user feedback at all stages. Collecting actionable feedback and delivering it to designers and developers lets you focus on what elements of the backlog can be addressed in which sprint, and understand what’s most important to users to ensure that development resources don’t get misused.
The acquisition of Telerik by Progress has brought its tooling into a cross-platform mobile development platform you can use with your choice of IDE, and a cloud-hosted test platform to ensure your code works across multiple devices. Progress also provides a set of Visual Studio plugins for its test suite which tests across multiple technologies using tests that can be written in familiar .NET languages.
Any ALM solution must go beyond the code of an application and drill down into the APIs it interacts with and the data it uses. That’s why it’s good to see Visual Studio 2017 including Redgate Data Tools as part of the suite available through its installer. ReadyRoll Core is included for handling the automation of database changes, with tooling for source control as well as database development. Using tools like this you can reduce the risk of errors from database upgrades and safely deploy new schema and templates. Other tools included add improved SQL code completion as well as tools that simplify the process of searching for objects across the many databases that you’ll find in a typical enterprise-scale application.
Beyond the code
Visual Studio 2017 and its associated tools give you much of what you need to deliver an ALM solution to your development team. Mixing cloud and third party tooling lets you pick and choose the elements you need whatever the code you’re building, whether it’s a simple application for use inside a business, or a cross-platform cloud-powered app with mobile clients on Windows, iOS, and Android.
Whatever combination of tools you use, ALM lets you go beyond your code, giving you a deeper understanding of what your code needs to do, why it needs to do it, and how it’s going to be delivered. It means your apps can be better targeted, better designed, and much more reliable. For developers, architects, project managers, and for users, that’s all going to be a big win.