Home / IT & Computer Science / Business Technology / Microsoft Future Ready: Continuous Integration Implementation / Feature Flags
Feature Flags
.
Hello, and welcome back. We have successfully completed our 101 with Git. So pat yourself on the back. That was quite a bit of a journey from understanding why distributed and centralised version controls are so different, and why it makes more sense to have a distributed version control system when you’re trying to do DevOps. Then we looked at how to get hands-on with Git on a day-to-day basis– the usual commands of committing code, pushing, pulling, syncing doing it from Visual Studio, Visual Studio Code, and then the command line. Then we moved forward and looked at what it takes to automate within a source control. We looked at Git hooks, both at the client side and the server side.
And then we looked at pull requests, and realised that if you ask me– especially when you’re working in a geodistributed team. After that, we looked at a proper branching structure, followed that through with a demo. And now that you feel that you know source control well, it’s worth looking at the other component of continuous integration, which is compiling the code and running the unit test. So welcome back. This is exactly what we’re going to do in this demo. We’ll set off on a journey to first create our first build pipeline, and then take it all the way to continuous delivery. But that’s going to take a few steps. So in this section here, we’ll absolutely just focus on continuous integration.
The build system within Visual Studio Team services has gone through quite an evolution. The first generation build system was introduced with TFS 2005. It was XML-based and entirely driven by MS Build. Well, it was good, but it had its limitations. You had to script stuff within XML, which was very tedious. So the user functionality, the user experience wasn’t great. Then came the second generation, which was XAML-based. It allowed you a very cool workflow, using the Windows Workflow Foundation, where you could go out and set up conditional branches of execution within the build process. But that meant that you could not run it on non-Windows machines. You always needed Visual Studio or a XAML editor, which as it is quite heavy.
And this was introduced back in 2010. So it has its pros and cons. But it wasn’t cross-platform, which was a big limitation. In 2015, TFS 2015, Microsoft came out with the third generation of the build System, which is called Team Build. Now, the design principles of Team Build– the first principle was that it has to be cross-platform. Let’s try not to create a language. Let’s try not to create a new system altogether. But let’s just keep it very simple and open and cross-platform by giving you an executioner, which can orchestrate any tasks. You tell it what task it needs to orchestrate, and the tasks that you provide should be open source.
So you can look at them, you can improve them, you can create your own. But the key thing is, it should be cross-platform and pretty light. And that’s exactly what’s been delivered. Team Build is an extensible task-based execution system with a very rich web interface that allows you to author a queue and monitor builds. It’s fully cross-platform, with the underlying agents being open source as well. They can natively run on Windows, Linux, Mac. It provides you out-of-box integration with centralised and distributed version control systems. And it works on any platform for any app. So we’ll see some of that in action as well later in the demo.
But I would encourage you to go off and check out the Team Build agent and the task repositories on GitHub. It’s very popular. Plenty of folks on it. And so if you want to add stuff to it, then go for it. Enough talking. Let’s get right into a demo. In this demo, what we’re going to do is we’re going to create our first pipeline. Let me just flip right into the demo here. So what I have here on the screen is a new repository that I’ve created. I’ve called it Summit. And the Summit repository, at the moment, has two projects in it. The first project that it has is a web project. It’s just a vanilla blank asp.net project.
And then the second is a default unit test project with some three unit tests in it. If I go back here and I click on my repository, I have an option to create a build for this repository. If I click that, it takes me right into the build workflow. Again, you don’t have to follow this path. You can of course navigate directly into the build hub. But by choosing that button, it pre-takes all the repository configuration, and can detect a few things in the way of doing that. So the project types we have are best suited for Visual Studio at the moment. So let’s select the Visual Studio template.
But again, you don’t have to select a template if you’re doing something bespoke. You can obviously start off with an empty process. If you scroll down, you would see that there are plenty of pre-canned templates available. So if you’re doing Android development, or even if you’re doing Java or Service Fabric, or if you’re just taking stuff on from Jenkins, then all of that integration is available. And it’s pre-canned so that you don’t have to write it off yourself. So when I click Apply, it gives me the list of tasks for my Visual Studio build type. There are a few here. The first one is Get sources. Now, at the moment, I’m getting the sources from my repository here called Summit.
But by no means does the repository need to be within Visual Studio Team services. It can natively compile and integrate with GitHub with your own custom Git repository and subversion as well. The next option is to restore all the NuGet package references that I’ve taken within my solution. Again, this is going out to the public repo. But if you set up your own private NuGet repo, then you can configure the path to that. The Build solution just uses MSBuild to detect and compile the code. And then the test task is just looking for tests using the DLL naming convention that’s specified here.
And then there is an option to specify which version of Visual Studio you want to use for the test execution. I’m going to change the test task from V1 to V2. Again, that’s a pretty cool feature within the Team Build system, where you can have multiple versions of a task available within a pipeline. And the preview tasks, you’re not forced to pick them up right away. But it starts to show up here to say there is another version available. You might want to try it out. And in this case, we can try it out, because this version too offers code coverage natively.
So I’m going to change the version to 2017 and enable picking up the code coverage, so that once the tests are executed, I can see what portion of my code they’re actually covering. The rest of the settings, you don’t really have to change. This is simply publishing the symbols, ie, the PDB file. So it aids you when you’re debugging your code. And then the next option is to take the compiled bits and save them in an artefact repository, which is hosted within Visual Studio Team services. So without making any further changes, I’m simply going to save this build. And I’m going to go into the Options section and change the repository from Hosted to Hosted Visual Studio 2017.
That’s because I’m taking a dependency on Visual Studio 2017. At this point, I’ll click Save again. I go back to Tasks, and I will click Queue. Now, at this point, I can review the specifications and click Queue. At this point, Visual Studio Team services is going to take the definition, identify an agent up on the server, and then pass over the definition to the agent, which can then start working through the tasks that have been defined. It can usually take a minute or two for the agent to be available, but it’s pretty quick.
As you can see, it’s starting to execute the build. The first task was to go and download the source code. It’s actually going to do that once it downloads the actual tasks that it needs to execute. Now, this is another great enhancement in the Team Build now, as compared to the previous version, where this is giving you the live view of the agent. Previously, you didn’t really have a live log, so you had to wait for the build to finish to figure out what was going on. In this case, the console gets updated in real time.
Great, so the build’s complete now. You can see the logs here, which is a great way of seeing if things failed. You can go through them in detail. You can download them for later as well. If I go in the Code coverage section, it gives me an option to download the code coverage. I can see the full test execution details here as well. And if I had any failed tests here, then I’d be able to see the stack trace, and click on it to actually get navigated into the code, which will reflect where the test had broken. I have an option to see the test execution details.
And then further on from here, I can actually pin it to the dashboard. This is something I’ll cover in the next video, anyways. So I’ll just skip through this, go back into the Edit build definition here, and show you a few more options. The first is Variables. It is a way of specifying constants or values that you want to use within your build workflow. Again, this is something we’ll cover separately. Triggers is where you would specify what is the execution model for the build, whether it needs to be triggered every time code is committed, or whether it’s scheduled to run once in whatever time span you define.
And if you enable this, you have an option to turn on the build based on repositories or specific file types as well. I’m going to leave this switched off for the minute. And the Options section gives you the option to specify the build numbering format. Enable the badge– again, this is something we’ll cover in great detail when we talk about build versioning. And then this is where you would specify where you want your build to execute, whether on the agent, which is hosted by Microsoft, or on a private agent that you’re hosting yourself. The retention policies are defaulted to 10 days and 30 days.
But you can, of course, change that if you want to retain the builds for a longer period. And History is where all the changes that you have made to the build definition, are recorded and you have a way of comparing the changes that you’ve made. So if you make any changes that tend to break what you have done, then you have a way of going back as well by simply right-clicking, and then saying restore the previous version. So that that’s it, really, for this demo. Let me just formally switch this to Continuous Integration, because that was the goal of the video– to set up our first CI build.
In the previous learning step, we discovered Deployment Groups in Release Management and how these deployment groups can be used to phase deployments to multiple agents.
In this video, we will demonstrate the functionality of feature flags. We will look at an open-source framework that’s available (which we can get from NuGet) and which has all the functionality that you need to get started with feature flags.
What are Feature Flags?
Feature flags, commonly known as feature toggles, is a software engineering technique that turns select functionality on and off during runtime, without deploying new code.
This enables teams to make changes without pushing additional code and allows for more controlled experimentation over the lifecycle of features. Because of this, feature flags enable many novel workflows that are incredibly useful to an agile management style and CI/CD environments.
During development, you can simply wrap desired code paths in a feature flag. These essentially act as IF statements.
Benefits of Feature Flags
Feature flags enable code to be committed and deployed to production in a dormant state and then activated later. This gives you more control over user experience. Apart from this, feature flags also:
- Validate feature functionality
- Minimise risk associated with deployments
- Modify system behaviour without disruptive changes
Feature Flag Use Cases
Feature flags enable a variety of use cases for development teams.
- Product testing by gradually releasing new product features.
- Conducting experiments such as A/B testing
- Migration of data that requires dependent application code changes
- Restricting the audience pools and toggling features on or off during canary launches
- Use as a system outage tool
- Separating code changes in continuous deployment
Before you move to your next learning step, Automating Recovery and Rolling, please take part in the discussion.
Join the discussion
Most of us have seen the movie The Matrix. What pill would you choose, if you had Morpheus asking you? Red pill for the truth of reality? Or would you pick the blue pill and continue to believe an illusion? What if you wanted to try both and then choose? Unfortunately, that wasn’t possible in the movie, but in software, with feature flags, it is possible. Discuss why this is the case using an example.Use the discussion section below and let us know your thoughts. Try to respond to at least one other post and once you’re happy with your contribution, click the Mark as complete button to check the step off, then you can move to the next step.
This article is from the online course:
Microsoft Future Ready: Continuous Integration Implementation
Created by
This article is from the free online
Microsoft Future Ready: Continuous Integration Implementation
Reach your personal and professional goals
Unlock access to hundreds of expert online courses and degrees from top universities and educators to gain accredited qualifications and professional CV-building certificates.
Join over 18 million learners to launch, switch or build upon your career, all at your own pace, across a wide range of topic areas.
