Dapper DevOps

From agent to fleet, the next step in Agentic Engineering

Sun, 22 Mar 2026 00:00:00 +0000

The next logical step in Agentic Engineering happens when teams move from individual developer augmentation to agentic delegation. That’s where two key patterns start emerging: full delegation and local parallelisation.

Full delegation

This is the easiest one, and it usually involves agents both local and remote: you choose a requirement and hand it off to an agent entirely, remaining involved only for review and comments. Have a look at this example:

This is a typical example of full delegation: the discrete requirement is handed-off to the agent, which works on its own. Once the session is over, a developer can review the output and comment or even change model (like I did, moving from Codex to Sonnet). The agent continues to iterate.

The other interesting thing is that in this case my agent is going to provide me with evidence of the result. This is a super useful behavior which started recently: all I have to do is to check the output and validate.

This is obviously not applicable to everything, but in many cases it’s a very easy way of checking and allowing for quick iterations.

Local parallelisation

Local parallelisation gives me the ability of running multiple agents against the same requirement, eventually merging these changes. The big thing here is that agents will run in parallel in their own worktrees so they are independent of each other without a sprawling number of branches.

Phase 6 here comes from a SDD session I launched to implement some API changes, whilst the UI was being worked on in parallel by another agent. These changes are implemented via the Copilot CLI:

Using the CLI means that these sessions will run in unattended fashion, surfacing information in the chat window as always but without a continuous interaction (except for authorising tasks and commands, which remains up to you).

Fleet of agents

The Copilot CLI natively support fleets of agents, via a /fleet command. This will orchestrate the set of agents from a single session and drive execution with the specified models, commands, etc. It allows for complete parallelisation of work done via agents.

What’s next?

The next logical step would be running agent-friendly backlogs with a built-in persistence system acting as memory. I already said it’s going to be the next big thing didn’t I? 😀

An early example of this is Beads, which replaces the manual plan stage of each requirement with a fully-automated dependency graph, enabling multiple agents to work on a single, larger piece of work.

Agentic Memory is the next big thing

Sat, 28 Feb 2026 00:00:00 +0000

I am on the way to DDD North where I am going to talk about Agentic Engineering, and one of the key aspects of my talk is the generational evolution of GenAI tools for developers. Given the pace of change in our industry I believe we are already bsing a second generation of tools and assistants, and we are just about to leap on a third one - the reason being Agentic Memory.

With the current crop of tools, you are instructing agents via multiple layers of coding instructions, a constitution when it comes to SDD, etc. These are all artifacts you (or your team) need to maintain at all times to ensure the best results. Guardrails are implemented, practices described, etc. All because today your tools cannot learn directly from usage, expecting instructions or waivers before execution. Some workaround existed with tools like Basic Memory to persist memory files to be fed back to agents, but it was neither smooth nor fully integrated.

This changes with the implementation of Agentic Memory.

GitHub and Anthropic have them already, and there are signs of this being imminent for OpenAI too. This will lead to a new fundamental shift in maturity, leading to better interactions with models and agents.

Think about it this way: today you are telling what to do to an agent all the time. Correcting mistakes over and over again. You become more and more prescriptive, extending coding instructions to a potentially large and hard to maintain artifact.

With Agentic Memory, your corrections will stick. Agents will learn. And in enterprise environments this will lead to a much higher level of predictability, which is super valuable for heterogeneous teams.

It’s not early stages or something in a far distant future. If you have it enabled in your GitHub organisation, you will see a section in your repository settings (empty as I just enabled it for my repos):

Documentation tells us they will be available as individual memories per session, so linked to either code reviews or Coding Agents sessions:

The most important remark here is that memories will be correlated to code that exists, so they will become part of the context in all intents and purposes, all self-contained in each repository. They will be flushed after a month if unused to prevent staleness, and retained otherwise.

This will be the next generational jump in DevEx for GenAI, so instructions will remain as guardrails whilst every repository will evolve by its direct usage. What becomes fundamental here is codifying enterprise- and organisation-wide instructions that leverage memories explicitly, rather than relying on a proliferation of repo-scoped memories, and it’s something we are already doing today with multi-layered instructions - so the core concept remains the same, with an enhanced execution.

The key difference between vertical and horizontal GenAI assistance

Wed, 21 Jan 2026 00:00:00 +0000

I answer this question at least once a week so I will use this as a more permanent signpost 🙂

What is the difference between GitHub Copilot and Claude Code/OpenAI Codex (or any other vertically-integrated GenAI assistants)?

The answer might be simple, however there are a couple of nuances to think of. Let’s have a look.

Model availability

This is the obvious one, and we kind of talked about it in the past. With GitHub Copilot you have a choice of models you are not going to get with other tools.

Do you want to mix models from different providers? It’s a selection on a dropdown menu. This flexibility is not available with other providers, and will give you the opportunity to switch, chop and change models as you see fit based on the best experience you get.

It is a very personal choice in the end, and it’s a unique selling point of a horizontal GenAI assistance.

Workflow integration

In the IDE, the experience is different remarkably different between the two.

GitHub Copilot is a hands-on assistant, which is very available in your environment no matter which mode you are going to use it with. Most of the experience is centered by default on the single developer, and puts severe importance on context.

Code completion, inline generation, etc. are all typical use cases for developer augmentation, where having the tool accelerates the unitary task being worked on. Agents can be local or cloud-hosted, however they run in relative proximity to your work even if you delegate tasks to them, as you need to be very prescriptive with the context you provide them.

GitHub Copilot is also heavily integrated with the GitHub platform, and it’s a unique team advantage. It’s like getting additional capacity out of a magic hat for specific tasks like Pull Request reviews and security remediation via Autofix.

On the other hand, any vertically-integrated tool has a remarkably different paradigm: even if they might be available in the IDE, they put a lot of effort in repo-wide context and CLI accessibility. They work against the whole repository building a context independently, and the agentic experience is way more delegated and hands-off compared to GitHub Copilot.

When I work with Claude Code for example, it is still very developer-centric however delegation is more wide-ranging. The CLI is the most powerful tool to use with it and it has high context awareness.

OpenAI Codex has an even stronger delegation system and runs mostly asynchronously, it’s very task-based and gives its best when performing isolated, wide-ranging implementations or tasks, so the IDE and the interactive experience is almost irrelevant for it.

Is there a silver bullet?

No.

The level of comfort with innovative ways of working and practices will obviously skew things one way or the other. Platform integration might or might not play a part at all. Repository availability and solution convention can be disruptive either way. There is no clear winner to be had here, but just the best choice out of a very crowded field.

Much of the choice also depends on the preferred ways of working of an individual or a team, as well the governance structure in place for developers, which might limit or hamper any of these tools in an expected way.

Eventually, one does not exclude the other. I saw organisations using both technologies for well-defined, discrete use cases and building a unique multilateral approach.

So no single winning choice (sorry!) but rather lots to think about in your own context and your own organisation.

Why your choice of model matters

Sat, 06 Dec 2025 00:00:00 +0000

I am sure you are familiar with the fact GitHub Copilot offers you an incredible amount of models to choose from:

A question I often receive is “so which model should I choose for my day-to-day work?”

The answer is not as straightforward as you might think, and here is why.

There is no single model to rule them all

You should not use a model as your singular, go-to, general-purpose solution for every problem.

Every model will have pros and cons, and there is a nice documentation page showing not only what a model is very good at, but also its system card, where you can find information about the safety assessment and the validation process used during training - something we discussed in a previous post.

Take advantage of each model strengths

Knowing this, you can break down every task into smaller units, identified by complexity. You don’t have to stick to a single model, and you’ll have to determine what’s the choice based on the type of task you do.

For example, the first thing I would do with a complex task breakdown is to engage a model with deep reasoning capabilities like Claude Opus 4.5 or Gemini 3 Pro in Plan Mode, in order to define a list of simpler activities to do. This is where your really need reasoning capabilities, and it should be the first activity to do regardless if you want to be efficient about your Premium Requests quota as well.

Following that, if something is a pure coding problem, I would go with something lighter and quicker however. still very much code-focused like Claude Sonnet 4.5, unless it’s a really deterministic and defined problem where a lightweight model the kind of Claude Haiku 4.5 or the new GitHub Raptor Mini will do.

If instead we are looking at a verbose documentation task, the best balance comes from the OpenAI models are the ones with the best articulation, however Claude Sonnet will do well in that because of the code-heavy context.

You should not switch all the time, find what works for you

That said, I would not recommend to choose a specific model for each and every task. Over time you will develop a higher level of maturity in prompt and context engineering, and coupled with multi-tiered coding instructions you will get to a point where your model choice will be one-per-type of task.

It will be important to keep up with the continuous development we see in the field, so whenever something new comes out swapping out models for test runs on well-known type of activities will be the benchmarking exercise you need to find the most suitable model for your workflow. It will become very personal after a while.

Remember your custom models

This is not for everyone, I get it, however don’t forget the models offered by the service are only an ‘as a service’ offering. You can plug your own models, either local or hosted, so to use something that has been tailored on your own needs or codebase.

Ollama in particular is the one to look at if you want to run a local model, something we are and we will be doing more frequently than ever.

A reflection on the risks of GenAI

Sat, 15 Nov 2025 00:00:00 +0000

Earlier this week, Anthropic shared details about how a hacking group used Claude for a highly sophisticated espionage campaign against a number of organisations.

This obviously sparked a number of conversations around the topic of security of GenAI tools for developers, and I ended-up explaining to some of our clients that even if they wanted to add their own security process and vetting (pointless, we’ll see why) they wouldn’t be able to do anything with the same speed and efficiency as Anthropic.

This begs the question though… what can an organisation do, realistically, about it?

Accept that complete prevention is not possible

When you are introducing a GenAI-driven tool you must accept a degree of risk. Risk is, specifically, around the speed of execution for malicious intent coming directly from within. Let’s have a look at an example: if you ask GenAI to help you with something, it will really try to help you if you use a somewhat advanced model (Claude Sonnet 4.5 here):

Note the latter stage of this: “…let me create a quick start script”. This is not a simple ask-iterate-execute loop, but rather a full-blown reasoning cycle which leads to unexpected actions. In this case the example is positive, the tool created a whole script to aid with a certain piece of work, but it begs the question: can you restrict this? Short and definitive answer: no.

When I say no, I mean without restricting unnecessarily all the valuable functionalities that you get with more advanced models. Realistically, do you believe you can do better than your supplier?

Microsoft, GitHub, Amazon, Anthropic… they all perform extensive testing before releasing models for consumption on their platforms. GitHub talks about it here, covering their AI model evaluation process, and if something is released on their platforms is incredibly unlikely you would be able to find something they didn’t.

Also, this is a service. If this was your own model you could run something like modelbench, however you have to implicitly accept the risk as you cannot really do much more than they do, given you are just a downstream consumer.

Some things don’t really change

What I always bring up to CTOs, is that the risk here is not new. You have a new vector, not a new threat in itself. The full report is a very interesting read, as the way Claude ended-up being used was to speed-up ~~hacking productivity~~ tactical execution work (sorry 😆) and it was heavily reliant on jailbreaking and rogue MCP servers.

The jailbreaking process is novel, as it managed to bypass the safety guardrail Anthropic setup on the model. That’s the core issue, and they moved very quickly.

Whilst you can’t do anything about jailbreaking (that’s a supplier-managed guardrail and Anthropic already fixed the pattern), what you can do is control MCP servers and, obviously, monitor the environments from where activities are carried out. Nothing that a good, old SOC can’t do, and it will still be linked to one or more users via network traffic.

Do it for real - Agent-driven prototyping

Thu, 23 Oct 2025 00:00:00 +0000

How do you really harness GenAI in an engineering organisation?

I answer to this question at least once a day. And my (long) answer is hard to digest. It involves bottom-up empowerment and, most importantly, disruption. And with disruption, the reaction is always the same:

But we already have a critical programme of work we cannot slow down! Our engineers can’t get distracted with this.

Well let me tell you… you are on the road to irrelevance. Do you want an example? Let’s do this.

My persona

I haven’t worn a developer hat (professionally of course) in ages.

I can write code, I can help and troubleshoot, but ultimately I haven’t been a full-time engineer in over a decade, I would be doing a disservice to developers if I were to call myself one.

Yet I still dabble with code because I believe it’s critical to be able to remain at the forefront, and every good leader should put their money where their mouth is.

If I do something more than twice I script the hell out of it. Infrastructure as Code, automation and pipelines are second nature. Backend development is still fun. However I never liked any form of JavaScript, and I tended to avoid it. Until now.

My use case

I am an avid retrogamer, to the point I have a CRT TV in my office as well as a number of consoles and a gaming PC. And to go with all of that, obviously, there is a spreadsheet keeping order in my game collection.

I decided to replace it with a simple web application, and rather than going the usual stack of .NET and my comfort zone, I decided to do things in an entirely different way: GenAI-first.

The initial prototype

As I said multiple times, I love GitHub Spark. It gives developers a way of seeing ideas turn to reality quickly and without the burden of scaffolding. So that was my initial choice:

This took less than 30 minutes. It was mostly about explicitly calling out what I wanted, in detail, and iterating on small requests. My initial prompt was very big though, as I had listed out the features I needed.

This prototype is no small feat: it has CSV-based import and export logic with delta manipulation, category management, search and filtering, proper UI. It’s a real application, not a Hello World of sorts.

Leave the prototype alone!

Once you are happy with the result, Spark lets you publish a repository with the content of your Spark:

Now, this repo is a fork of the template GitHub uses for a Spark, but most importantly it is directly linked to your Spark that is running.

For this reason, you should not work on this repository unless you want to tinker with the frontend. Given we want to get to a real environment, you will need to tear the key-value store apart and replace it with another solution, breaking the Spark.

You should be doing what any developer in working in a real Agentic Engineering organisation would do: fork it from your local repo to another, organisational one. I happen to have this setup as well (account v organisation) so I forked it as-is into my organisation:

Now we are talking! A quick npm run build confirms it works on my machine. Or it loads, rather.

Getting on Azure

Infrastructure-wise, we will go for the bare minimum: an Azure Storage Account with Table Storage for my key-value storage, and an Azure Static Web App for the frontend. Simple enough.

The first thing to do once you go down this route is to modify the default GitHub Actions workflow that Azure creates when you link the repo to the Web App:

The app_build_command is needed because Spark uses Vite for building the app, and it’s not the default stack used in Azure. Don’t try any other way, it won’t work (changing the directory, etc.), easy enough though with a reasonable understanding of what you are doing.

Also remember to change the Node version in the package.json file as the packages in use target Node 20+:

This will allow you to get a green pipeline and have an empty Azure application which cannot save data anywhere. Still, it’s outside of Spark now!

Agents for the heavy lifting

I definitely don’t want to start fiddling with code I haven’t written, especially in an unfamiliar environment: enter my GitHub Copilot Agent Mode, which will replace the key-value storage with the appropriate Table Storage calls:

It worked for a while, and it not only implemented the logic but also generated plenty of documentation supporting everything. Except it did not work at all.

Interestingly enough, the final output was a list of potential troubleshooting steps to take:

CORS looked like the culprit here. Once configured in the Storage Account, the application magically worked both locally and on Azure.

How long did it take?

As insane as it sounds, two hours. It was more the effort of getting the Spark right than anything else. I had two Pull Requests running 25 minutes from each other, and that was it:

Obviously, an experienced developer would be quicker!

What’s next?

If this was a real product and not just a one-off experiment, the logical next step would be to build more features using Coding Agents. That would be an extremely quick way of getting onboard with new development (or refactoring/bugfix) exploiting GenAI assistance to the max.

There might be more fixes or enhancements I can do on the fly with Agent Mode, or even coding them directly myself. The amount of documentation is brilliant and really helpful. Agent Mode even generates diagnostic tools and troubleshooting scripts when prompted correctly, which are super invaluable.

That is where real Frontier Firms are heading, harnessing a new way of working and leveraging change and disruption for industry-altering improvements. This is where we are heading, collectively.

If you are still worried about your programmes, it might be time to reconsider and trying to foster some experimentation, because if you are not doing it… your competitors surely are.

If you are down because of the AWS outage, it's your fault

Tue, 21 Oct 2025 00:00:00 +0000

So… your systems went down yesterday because of the outage on the US-East-1 region. Global impact, massive problem, I agree.

Now, dear organisation… it’s all your fault. Especially if you claim to be cloud-native because you use a hyperscaler.

Why?

Because I saw far too many instances of organisations turning down the right decision, the right design, the right implementation that takes a multi-region implementation seriously.

You had the option of enabling geo-distribution, using regional replication, designing around Availabilty Zones, anything that gave you true multi-region resiliency, and yet you didn’t. The reason?

It’s too expensive

The business impact of penny-pinching on your Opex

Let me be super clear on this: if you use a hyperscaler as you would use a datacentre, you are not cloud-native. You are just running a more expensive datacentre without a hardware amortisation plan.

You might be benefiting from the elasticity of the Public Cloud, moving from Capex to Opex, however you have to stick to a financial envelope designed for on-premise kit. So you end-up penny-pinching.

Not using the real HADR features of Public Cloud. Faking a highly available design that just accounts for component or system failure rather than geographic or catastrophic failure. The list goes on and on…

Change your risk modelling

You need to accept that using a hyperscaler requires a radically different approach to architecture design, risk modelling and financial estimation.

Besides the mindset shift required in technology, think about how much risk is actually palatable…

If a region goes down, so does your business. Can you accept being fully offline for a variable amount of time?

SLAs are pointless if they are your only certainty in terms of resilience. Model your risk mitigation based on this answer to start with, and use the Public Cloud as it’s supposed intended to be used if you want to be a true digital organisation.

Custom personas in GitHub Copilot

Wed, 15 Oct 2025 00:00:00 +0000

I talked about Custom Instructions in the past, but can we go further?

You can build your own persona to pair with when using GitHub Copilot. Think about specific, role-defined activities you need to perform on the regular, which would benefit from a specialist rather than a generic approach Copilot could have.

Enter Custom Chat Modes. This is different from the custom command, and it will extend the Modes (think Ask, Edit, Agent) you have in your IDE.

This is where you build your prompt. Be specific, detailed and ensure you cover the behavior you need:

Now, there is a lot more you can do. First of all, you can select the MCP tools you want to add (in this example I used all the built-in ones). Crucially, you can also specify the model you want to use.

Once done you can save it in the .github/chatmodes folder, using a <persona>.chatmode.md name”. This will load it up in Visual Studio Code:

Let’s test it!

You can build as many Personas as you need, and having specialised assistants really goes a long way in a GenAI-augmented developer experience.

Moving from vibe coding to Agentic Engineering

Wed, 24 Sep 2025 00:00:00 +0000

Vibe coding is great. There, I said it.

You know how much I like GitHub Copilot, GitHub Spark and all the other GenAI tools that allow someone like me, somewhat removed from being on the front row of development action, to actually be really relevant by quickly scaffolding and, eventually, creating new working code that solves someone else’s problem.

Now… it’s all very nice and well, but it does not work at large scale and it does not work in structured environments where variance is frowned upon and adherence to best practices and standards is vital for code to be shipped to production.

And that’s the way it should be in order to avoid piles and piles of technical debt from accumulating in your codebase. What if I wanted to leverage AI to do more than just scaffolding, and drastically accelerate my SDLC?

Spec-driven Development

The answer is spec-kit, a lightweight framework that translates specifications into individual chunks of work that can be delegated to one or more Agent.

This is a particularly sensitive topic in enterprise environments: as of today you had to craft your prompts very carefully otherwise risking a disconnect between your requirements and the code being produced. This is no more.

How does it work?

You install Specify and you setup a project with spec-kit:

You will have three additional commands for GitHub Copilot in Visual Studio Code:

These are the three fundamental commands of SDD - it follows a why-what-how paradigm:

Why = Specify the vision
What = Plan the technical implementation
How = Break down the specification into actual Tasks

They will live off a file called constitution.md, which acts as the immutable principles upon which the commands will run, and most importantly, is the de-facto memory for your key commands:

Before diving into details, keep in mind that every command template lives in the .github/prompts folder, they are Markdown wrappers towards the specify CLI to be used by GitHub Copilot (or your favourite assistant) and everything can be customised and extended as needed, so these are effectively templates.

Specify

/specify will read your requirement and generate a detailed breakdown of your acceptance criteria, the sub-features and components of the requirement, and every functional detail required for a solid implementation.

This specification is the functional understanding of the requirement from the GenAI perspective:

Your quality gates will be an explicit part of the specification:

Plan

/plan is the command to be supplied with the technical details of the implementation you want the Agent to follow, so it can generate an execution plan for your Agents:

Something really interesting here: the constitution is enforced at plan time:

That’s why that file is central to the whole idea of SDD.

Tasks

Once you are ready to proceed, you can generate the task breakdown:

You will get an interesting list of tasks that can be given to one or more agents:

Here you can add or define any key dependency, library, etc. to remark to the agents for implementation.

Implement

As a first timer, I wanted to observe how the tasks were implemented (you can run /implement otherwise), so I manually triggered the execution in GitHub Copilot Agent Mode:

It was really interesting to observe the iterations and how it tried to solve problems, including with running tools:

It took a while…

And eventually, it delivered:

And yes, it actually works 😀

So what?

The key difference between vibe coding and agentic engineering is the repeatability of a solution. The key foundation of Agentic Engineering is giving developers more time to focus on the actual value-added, rather than diluting their flow state with repetitive and sometimes tedious activities.

For this to happen, developers need to be coordinating a number of agentic processes so that they can then review and augment what is otherwise machine-generated code to the expected standard.

Spec-driven Development bridges that gap today, giving teams a way of exploiting all the power of GenAI for developers without having to manually keep an eye out for every single execution. It’s quite literally at the frontier of our industry, I could not more excited for future developments!

Build a Custom Copilot Chat command in seconds

Wed, 17 Sep 2025 00:00:00 +0000

A simple yet underrated way of accelerating standardisation in an enterprise engineering platform is to build custom Copilot instructions to bundle in your repositories.

Whilst that is very true, we should not just think of them as overarching, standard prompts that give custom information to our developers. That would be true of a copilot-instructions.md file in the root of the repository, however anyone can develop their own, just by adding a <command>.prompt.md file in the .github/prompts folder.

Something like this:

You will be able to invoke it from the /pirate command in Copilot Chat:

This would invoke the prompt (“can you help?”) with my pre-defined context setup for the command:

And it will result in… well, exactly what you’d expect 😂

It’s not magic, it’s not special, it’s just part of the GitHub Copilot infrastructure in Visual Studio Code, that allows you to create custom instructions.

Obviously, being a Markdown-based approach, you can also use it in your coding agents if you have something specific in them - all you have to do is to refer to them as part of your Agent prompt.

Why watermarking your code is a bad idea

Mon, 25 Aug 2025 00:00:00 +0000

The absolute number one request I get from clients rolling out GenAI assistance to their developers is:

I want to know how much code is generated by GenAI, by team, and even by person sometimes

I think it’s a very bad idea, for a number of reasons. Here is why.

It takes unnecessary effort

You want to know how much GenAI code is introduced in your codebase? No problem, it’s technically easy: if you want deterministic watermarking in your code (so not just relying on the involuntary patterns your LLM leaves behind), you will find a significant number of academic papers talking about how to add invisible signatures to your code, so you can then use a tool to detect said signatures and report against them. You can already find commercial platforms doing that on your behalf, for a fee.

You will obviously need to setup runtime automations in your CI pipelines, as well as dashboards, reports, ingestion into a data platform (?) and… you will still fail. Why?

Think about this: a developer starts writing code and they accept an autocompletion suggestion from GitHub Copilot. Do you:

consider that line of code AI-generated?
discount what the developer did? The suggestion might have been is so marginal it barely makes a dent in the code generated.

What if a developer amends GenAI-generated code? Does it count against your metric or not?

As you can see it’s a rabbithole you have no benefit from.

It dents developers’ confidence

Let’s say you gave up on the idea of running these tools and you just want a surface-level idea of how much code is generated. Lightweight, little effort for reporting. You end up adding a custom instruction to your repos along the lines of this:

Congratulations! You will have a bunch of lines watermarked:

Now, assume your developers need to work on these lines of code. Do they need to manually remove the GHCP GEN comment every time?

If so, it will cause a loss of productivity at a minimum, without thinking about how they will be incentivised in cheating the system, either by adding extra code themselves with the comment or actively avoiding to show usage of GenAI acceleration.

Doing this causes a significant loss of trust for developers, and it will have negative effects on developer productivity across the board. Is it really worth it?

Focus on the best practices

There is no substitute for DORA metrics, it’s that simple. You can derive your own, based on DORA’s and adapted to the state of the organisation you work in, and add forms of active measurement around the SPACE framework, however you will always end up gravitating around them because it’s the most non-disruptive and accurate measurement you can use for your teams.

The current state of Agentic Engineering with GitHub Copilot

Fri, 01 Aug 2025 00:00:00 +0000

2025 is all about AI with agents, and as always developers are at the forefront. There are layers to it though, and I keep getting confused clients approaching me about some of the possibilities. At the end of the day this is not just about tools, and Agentic Engineering is not about giving all your developers access to GitHub Copilot or Amazon Q Developer, but rather a cohesive approach to the end to end lifecycle.

We looked at a few things here, but these are just tooling examples. Let’s try to broaden the subject and summarise where we are as an industry point of view.

Assistants like GitHub Copilot are a commodity

As I said earlier, access to GitHub Copilot does not make your engineering organisation AI-native. In 2025 we should be well past the point of proving value for a rollout, yet I still talk to clients about it on a daily basis. Access to GitHub Copilot (or any other developer assistant) is table stakes if innovation is the top priority, and if you are not doing it, rest assured your competitors are. Costs are negligible compared to the value returned, the ability of giving developers an immediate boost pays for itself and there are huge positive implications - essentially every active measurement survey proves that, in each and every rollout I am involved in, so sample size is not one.

There are different ways a developer gets benefits from using GenAI, and it will ultimately depend by the way you use it. Regardless, it is a no-brainer.

Supporting developers

A developer is supported by GitHub Copilot when they use it in the IDE, regardless of the mode.

Code completion, Ask Mode, code generation and Agent Mode are all aimed at augmenting the work our teams do so they can add their specific skills and knowledge in the most efficient way, with every tedious, repetitive or otherwise time-consuming operation out of the way.

An example of this is Agent Mode. Copilot does something for your developer, but still their your direct supervision:

Supervision here is key: with Agent Mode your continuous feedback loop ensures the output is what you actually need. This is not an agent working in unattended fashion:

The immediate impact of using Agent Mode is that developers work on their codebase with significant acceleration, more than just using code completion or generation, and with tangible efficiency benefits.

Augmenting developers

Augmentation for developers is evident when a developer is able to scale significantly using Coding Agents.

A Coding Agent is real, unattended delivery where the developer only reviews, leaving the actual implementation to the agent itself. A developer can then start their flow on something else, and once the agent is done they can review, comment, and suggest changes. Look at this example:

This is a super crude user story. There is little context, zero information about NFRs, only a goal outlined: write the Unit Tests against a codebase. Yet, once I assigned it to a Coding Agent, it did that and more:

The interesting thing is that a Coding Agent can and will understand failure and remediation:

The way it works is simple: the Agent analyses the context from scratch, and it uses the whole repository.

That’s how it can understand the whole thing and delivers the functionality in roughly 15 minutes and you can still interact with it in a PR to trigger further work:

It could obviously be much more efficient as well, with custom instructions, environment setup or other features, but more on that in a future post 🙂.

Developer augmentation is not just pure feature generation: you can (and should) leverage Copilot Agents for code review as well, directly in your Pull Requests:

These two use cases alone are the foundation of Agentic Engineering.

What’s next?

The biggest difference with other tools or platform is that Agentic Engineering keeps evolving. Today we talk about GitHub Copilot Coding Agents, but Claude Code (to name an example) is emerging at breakneck speed and something else might come up next week or the week after.

Things will also go beyond the pure coding aspect of the developer workflow, Copilot Spaces is an excellent example. Think of it as shared context analysis for small scale (PBI, bug fix) implementations. It’s a brilliant brainstorming aid and it helps shifting left some of the effort required in a Pull Request.

Ultimately the goal for Agentic Engineering is to settle on practices and approaches where the platform works on your behalf and the developers can express multiples of their potential. Ideally, the platform should be something multimodel and extensible. GitHub Copilot is, frankly, both - so it is perfect ground for future developments. I am excited for what’s next!

GitHub Copilot Spaces is your rubber duck

Thu, 05 Jun 2025 00:00:00 +0000

The GitHub ecosystem keeps growing and GitHub Copilot has got a new, preview feature… that looks like a product. Copilot Spaces.

It’s a brilliant tool to go beyond code, and use it as a rubber duck in any situation. Think where you need to search large amount of documentation, or code.

For example, I have 13 years of posts in my blog. I might not need to index all of them, but rather just the past few years. I created a Space just for that…

I gave it some system instructions to ensure its behavior is very tailored, then ingested the past few years of posts, leaving room for growth:

And that’s all: I can start prompting! With my model of choice, of course:

Of course this is a super-simple scenario. However imagine you need to brainstorm an idea or discuss something with a colleague… Spaces gives you that environment. It’s similar to Copilot Workspaces in many ways, but with more flexibility around how you use it.

Extensions approval status in Azure DevOps

Wed, 07 May 2025 00:00:00 +0000

I just noticed it today, it might have been around for a while… however if you are an Azure DevOps Administrator you will like this.

The Extensions settings page now shows the approval state of each extension:

If an Extension is considered a High privilege one, it will be highlighted, and in the details you can find what is the permission that is flagged as high privilege:

Extensions (and their lifecycle management) are often a time-consuming and critical part of the role of an Azure DevOps Administrator, this is a small yet very welcome quality of life improvement!

Infusing GenAI in Azure DevOps

Sat, 03 May 2025 00:00:00 +0000

I lost count of how many people come to me asking for AI features in Azure DevOps, and then seeing being surprised when I tell them that it’s actually possible to have an AI-enhanced experience with the platform. So this post brings a couple of examples to the table to try and settle the argument once and for all 😀

The AI model

In order to start, all you need is an OpenAI model - I use mine in Azure because it’s handy and convenient for me, especially for platform integrations. You an obviously use other hosting options, and that will introduce more custom work. However it’s all fairly reproducible everywhere.

I deployed a GPT-4 model, and I will be using it for two specific use cases: an AI Peer Reviewer for Pull Requests and a Custom Copilot.

The first use case is really simple, as all it’s doing is really just replying to specific prompts with payload data. The second one is more interesting, as it requires adding your own information to the model. Let’s have a look.

AI Peer Reviewer

There are several extensions in the Marketplace for GPT-powered review, however the majority of them are forked from this one. I like this particular one because it gives me the ability to customise the prompt used as input without having to build my own custom extension should I want to do that. This is particularly important if you want to tailor the prompt for specific rules or for larger enterprise usage.

This is what you need to add to your pipeline:

Remember to use the API_VERSION parameter correctly when configuring the extension - use the API Version shown in the endpoint demo in the AI Foundry and you will be fine.

The result is quite nice - you have an AI Peer Reviewer in your Azure Repos Pull Request!

Custom Copilot, like GitHub Enterprise

This is quite brilliant as it requires little effort in proportion to what you will achieve. GitHub Copilot Enterprise has a feature called Copilot knowledge bases - essentially a Custom Copilot for your documentation:

Why not having the same in Azure DevOps?

This requires a little more work: you obviously need to have Wikis in Markdown for your project(s), and then you need to upload them to an Azure Storage Account. If you want to get started quickly, just upload your Wiki content via an AzureFileCopy task in a pipeline. Once you do that, you can ingest the aggregated content in your model, enabling your own Enterprise Copilot.

It’s all it takes, given Azure OpenAI supports .md files natively.

How a pet project graduates to capability

The features themselves are fairly easy to craft and implement. If you want to make them robust enough for your organisation, you will need to use two things:

A coherent documentation strategy
Extensive usage of Pipeline Decorators

The first one is super important. You can have different file types at a stretch (look out on the documentation) however you really need to have a comprehensive coverage of your documentation to make this scale at organisational size, and you need to make sure you can regularly export them. Hence why Azure DevOps Wikis are so handy for this - chances are you already have all your documentation in Markdown there, so a regular export will do the trick.

For the second one, Pipeline Decorators take away the effort required to make this a compliance requirement.

Decorators will deploy what you need in every CI/CD pipeline. What you need is to inject a pre-job decorator that uploads the content of the repository to the Storage Account used by the OpenAI Model, and a post-job decorator that adds your chosen extension for GPT-powered code review with an execution condition similar to the one I used in the example above (and(variables['Build.Reason'], 'Pull Request')).

Taking care of these two things will make your Azure DevOps AI-infused with minimal effort.

What else can you do?

Can you do more? Absolutely. It all relies on adding data to the model, so exporting Release Notes, Test Reports, BOMs, even Work Items will give you more data to work with. And as you can see it’s easier than it sounds.

How I digitalised my analog notetaking framework in ten minutes with GitHub Spark

Sun, 27 Apr 2025 00:00:00 +0000

Vibe coding. Many people are talking about it, some are practicing it avidly, some are wondering how to actually do it. This post is for you if you are in the latter camp, or if you want to find out more about GitHub Spark.

GitHub Spark is an experiment from GitHub Next, and I am particularly fond of it. It gives you a development enviroment, an execution environment, a data storage facility powered by a key-value database and access to LLMs all via…prompts. Yes, prompts. All the applications are built upon React, and despite Spark being designed around natural language and prompt engineering, it still gives you access to the code so you can tinker with it as needed.

I had ten minutes between meetings, so I wanted to try something more than a Hello World or a sample to do list 😀 I tried to replicate my notetaking framework. It’s something I have been using for over 20 years: a notebook I carry with me for day-to-day notes, relatively unstructured besides a topic header and a date, coupled with a second notebook stored in my office where I summarise notes by topic in a much more condensed and analytical way. The latter one has an index, which helps me find topics at a glance.

With this in mind, I told Spark what I wanted to do:

And I got my skeleton up and running:

A couple more things…

Now, with a few more prompts I added extra features such as favourites and notes export, but this is not really the point. GitHub Spark gives you a way of editing your application in a very simple way, either via manual edits or directly within the code:

It gives you hints on what else you could add, a theme editor, a data explorer, logs and a way of adding prompts for LLB-backed features. It’s all there! And if you want to look at the code, you can:

You can also choose different LLMs. I used Claude Sonnet 3.5 for most of this application, however it struggled with the data export feature so I switched to GPT-4o and I managed to get what I needed that way.

The data storage layer is also pretty interesting: it is key-value, but it’s also JSON-based so you can nest things as needed. This is an example from my Formula 1 result tracker:

You are not limited to a single level of hierarchy, and it is quite flexible. This is how it would look once in the application itself:

I am using it more and more to create simple things that accelerate my day to day, what I like the most is the fact that it does not require any more effort than this, and it is super-personalised. I hope GitHub will make Spark as accessible as possible as I truly believe it changes the way we think of custom applications.

How about a Well-Architected (Framework) for Azure DevOps?

Tue, 18 Mar 2025 00:00:00 +0000

Someone asked me the other day:

You blogged about GitHub Well-Architected, it’s brilliant. Why is there no Azure DevOps equivalent?

Fair question, and I will try (and surely fail!) to keep the answer short.

Azure DevOps is different

Simply put, Azure DevOps is designed with a logical container (Team Project) segregating a slice of all the services available on the platform. Team Projects have always beem used to define Projects and store all the data related to them in a single place.

You always had code repositories in there, a representation for time (Iterations, to be defined in days) and space (Areas, representing logical subsection of your work). Everything is designed around these concepts.

This also affected the level of access control, which is super granular and allows custom roles to slice and dice access (or visibility) as needed.

Historically there wasn’t much consideration for this

Bit of a history lesson over here, with the customary nostalgic tear 🥲. Azure DevOps is based off a product called Team Foundation Server.

All the content sat on a single database for the longest time. Starting from Team Foundation Server 2010, Microsoft introduced the concept of Team Project Collections, and it started splitting up data storage. Git was not an option until Team Foundation Server 2012, everything was stored in a centralised Version Control System before then.

Between Team Foundation Server 2010 and 2012 is also where the codebase was forked to develop TFSOnline, which became Visual Studio Online, which became Visual Studio Team Services, which eventually became Azure DevOps Services.

One Team Project to rule them all

After so many years, we needed to move away from what we called “TFSGuide” (TFSGuide was the name of the file and the alias to send feedbacks to…) and onto something that was more industrialised. TFSGuide was a large collection of SOPs and designs every ALM consultant knew almost by heart.

This is where we started defining new best practices, which ultimately resulted in the “One Team Project to rule them all” approach. This is still very much the best practice, as Microsoft continues to update documentation on this.

It is in essence - everything in a single Team Project, as many code repositories, groups, teams, areas and iterations as you need based on your logical structure (teams, squads, products, CoPs, etc.). It works well and it’s considered the golden standard unless you absolutely need to keep things segregated.

There is one exception though, besides the segregation example above. You remember how much I like Pipelines as a dedicated serverless environment for platform automations, right? Let’s just say Two Team Projects to rule them all then 😀

GitHub Well-Architected, the ultimate guide to enterprise-grade GitHub deployments

Thu, 13 Mar 2025 00:00:00 +0000

Speaking with people the other day I realised so many don’t know about it!

In January GitHub released their Well-Architected guide. Clearly inspired by the Azure Well Architected Framework, it is a proper guide to setting up an enterprise-grade development platform, going well beyond pure tools and rather into design principles and ways of working.

It is an invaluable piece of documentation, so you can assess where you are against best practices and potentially add or improve some of your practices.

A sticky note for myself - enforce a .gitignore file

Sun, 26 Jan 2025 00:00:00 +0000

No matter how many times I do that, I keep creating new repos and adding a .gitignore file afterwards - so I need to enforce it after the fact (especially after you start bulding and you have the annoying build artifacts in your file system!).

This is literally a sticky note for myself 😃:

git rm -r --cached .
git add .
git status # to check for missed files
git commit -m 'enforced gitignore'
git push origin <branch>

Can I get GitHub Copilot without using GitHub?

Wed, 08 Jan 2025 00:00:00 +0000

I entertain this question at least once a week so let’s put a reference answer out once and for all 😀

I want to use GitHub Copilot but I am using a different development platform. Can I use it anyway or do I need to migrate to GitHub?

Short Answer

Yes, you absolutely can. GitHub Copilot primarily lives in the IDE so your code can live anywhere and you can use it.

Long(er) Answer

What organisations are mostly interested in are the Copilot Business capabilities, and GitHub Copilot is a developer tool, so it can be used on any code, anywhere. Even when the code is not in a Git repository at all.

It is also a SaaS product, so all it requires is somewhere for it to be billed to, which however needs to remain under organisational control for governance and compliance. It is called GitHub Copilot Standalone, and it is essentially a GitHub Enterprise organisation with no enabled features except for Copilot Business.

In order to get it, you need to contact the lovely sales folks at GitHub, and they will setup this special organisation for you.
Once done, you need to then connect an Azure Subscription so they can bill the metered usage of the product and you can start setting up teams for licence distribution to your developers. You can do this under the Billing settings in your Enterprise.

That’s all! I hope this helps. Thanks for asking 🙂

Developers in the age of AI

Thu, 14 Nov 2024 00:00:00 +0000

I just got back from Bucharest, where one of my sessions at GoTech.World was about what I believe is going to happen to developers in the age of AI.

Excitement

Excitement is really up there. I’ve been discussing AI at large with so many organisation for the past year, and there isn’t a single one of them that’s not excited about what AI can do for developers. They are at the frontline of this new technology, and the results for who embraces it properly are really out there to see.

My view of the world is very simple: with AI in their workflow developers can focus on what really matters in their day to day job, leaving repeatitive and time-consuming tasks to a Copilot of their choice. The productivity benefits are sizeable. People are happier. It’s a win-win from any angle.

When it comes to AI in new or existing systems, it’s still exciting. The potential market advantage of disrupting and accelerating existing processes in any industry is there for anyone to exploit, and it’s worth remembering organisations sit on a trove of data, which is essential fuel for a LLM. It’s up to them using this data properly.

Confusion

People are confused about the future, in particular about how development tools and platforms will evolve, potentially removing some skills and tasks from the usual day-to-day work. What’s going to happen when you have tools that today provide advice (GitHub Copilot) and tomorrow will evolve into headless Pull Requests (GitHub Copilot Workspace) for your developers to review?

Skills will evolve and adapt, undoubtedly. Over the past 12 months, for example, we introduced concepts such as responsible review and watermarking in the developer workflow. Prompt Engineering breached from the LLM world and is now essential for the GenAI-assisted developer to bring the most out of their Copilot. There is going to be a lot more permeating the developer space in the coming days and months.

Unease

Let’s be frank - the first source of developer resistance is fear of being laid-off due to the impact GenAI has on development teams. There is some risk for some types of developers, of course. But as I mentioned in the past, reducing teams by proportion of development productivity impact is a very short-sighted idea that I try to defuse whenever I can. There is simply no direct correlation as every developer is unique and operates in a different way.

Moreover, even AI needs developers, and not for training or refining. LLMs need to be harnessed and managed like any other resource, bringing DevOps and hyperautomation concepts into the mix. To name an example, a developer writing pipelines and automations for LLMOps is already AI-adjacent and they will be fundamental for any form of development of said system.

There is a lot on the horizon - patterns, products, services, etc. The world feels in a permament cliff-edge about how roles will evolve. Yet, it’s still early days to predict what’s going to be the future job description of a developer in 5 years’ time. It’s fair to say there is a mixture of excitement, confusion and, for some, even unease. However in my opinion the future is bright - there is going to be so much to do for a developer! I am looking forward to what’s next in the industry 😀

Brainstorming with Copilot Workspace

Sat, 09 Nov 2024 00:00:00 +0000

AI assistance for developers is not just for executing well-defined tasks - you can get a lot of value out of tools like Copilot by rubberducking or simply by asking explanatory questions to the assistant.

This is particularly true for new joiners to any codebase, the time it takes for anyone to be up and running is significantly less than what it used to be.

If you want to try that with Copilot Workspace, click on the Brainstorm button without any context or question:

This will give you a starter list of questions Copilot believes are applicable to your codebase:

Each question will be answered by an understanding of the code repository by Copilot Workspace - this not not just about a single file (as we got to know) but rather the whole of your code:

You can use this answer to understand the code at hand, and use it as a starting point for further development:

You will get amended code and documentation:

Now, it does not mean this will achieve exactly what you want. In this case, I don’t want a matrix strategy but rather the choice of running the build in either environmment. So I can ask to revise the answer:

Much better!

It did not, however, update the documentation. Let’s fix that:

Done:

This is a simple example however it shows how you can start an exploration and then implement something directly from the Copilot Workspace context.

If you ask broader questions, you will get broader answers:

Each will obviously kick-off a new session where you can implement the suggested changes.

GitHub Copilot Workspace is the true next step in the SDLC

Thu, 17 Oct 2024 00:00:00 +0000

Supercharging GitHub Copilot

Copilot here, Copilot there… yes, GitHub (and others!) Copilot is brilliant, but it only acts as a sidecar support to the developer experience. You will see a lot of productivity improvement, and you will have a much happier developer population, but it will be fundamentally linked to the team size and the organisation.

This is where things get interesting - Agents are the next logical step in a GenAI adoption journey. Agents are able to perform operations independently from the user, under supervision, leading to a precise outcome. They significantly help augmenting a capability, and are going to become prevalent in the next few years.

GitHub Copilot Workspace gives you Agents you can use to significantly grow what your development teams are doing. I think it’s a game changer.

An example

Let’s start with a controlled example: a starter application created with dotnet new mvc. Nothing special, nothing fancy, but assume for now that this is your existing codebase you are working with.

I am going to ask Copilot Workspace to implement a CI pipeline in GitHub Actions based on the code at hand:

This is where the true power of Workspace shines:

Copilot Workspace “understands” (it’s a LLM, it has no reasoning, but it can interpret things based on context as we know) what we are working with and what we need to do. It will generate a number of steps:

Each of these steps is going to be linked to changes to the code:

If I am happy with it, I can open a Pull Request against a branch. This will contain the work done by Copilot Workspace:

Now… I might want more. Let’s ask Workspace again:

I noticed the packaging step created by the agent is not what I want though, as I get an error in my CI workflow:

I can change it by asking again on the prompt box or by editing the file myself, and it will do what I need with the right level of information:

Now, this is a simple example. Imagine doing this with explorative branches, codebase explanation, etc.

You now have an Agent which can work independently on relatively complex requests, and you can steer its outputs with a few prompts.

The key difference

Why is it different? Copilot Workspace will break down a prompt into multiple actions, within the same context. So you don’t get a bounded code generation, but rather a series of independent actions which will achieve a complex outcome.

Agents can live independently as sessions, and you will always be able to track back or initiate new ones from the Development Platform. They are an extremely powerful tool for development teams to significantly improve the impact they can deliver against their backlog!

The industry is significantly changing, and tools like Workspace were unthinkable even a few yearsa ago. I am looking forward to seeing what else Copilot Workspace will be able to do within GitHub Enterprise!

Measuring the impact of your GitHub Copilot rollout

Fri, 27 Sep 2024 00:00:00 +0000

GitHub Copilot is amazing… but you can’t just roll it out all of a sudden with no planin a large engineering organisation!

Flipping the switch on without a proper configuration would be plain dangerous (think about he risk of accepting licensed code without training on triaging), but once this is addressed the most common thing I am asked about is:

how do I measure the productivity impact of GitHub Copilot?

Let me be clear: this not about replacing people with Copilot or reducing teams thanks to the productivity increase. GitHub Copilot is a tool, and I believe in people who can deliver better rather than more. Someone who uses Copilot on average delivers better code, and it happens thanks to the fact that the state of flow is not interrupted and developers can focus on the real, hard problems of engineering today.

GitHub Copilot Metrics Viewer

Using the REST APIs is absolutely fine, but sometimes you need to start quickly and with something visual. The folks at GitHub developed metrics-viewer, an excellent React application you can deploy anywhere. It will be connected to your GitHub Organisation (or Project, if you like) and it will give you a fantastic breakdown of metrics for your teams.

I use metrics-viewer heavily and I recommend it against alternatives like a custom PowerBI dashboard as there is a significant integration with the service. I think it is an excellent tool.

You can also find PowerBI dashboards if you wanted to, of course!

In both cases you need a token with manage_billing:copilot and read:enterprise scopes.

Why it is so important

metrics-viewer (have a look at their README, it shows quite a lot!) is a single pane of glass where you can monitor acceptance rates, hotspots, active users, etc.

It gives you a breakdown of languages in use, IDEs, etc. but most importantly you can see the plain API responses so you can potentially include the logic in your own systems!

Simplifying Build Farms with Managed DevOps Pools for Azure DevOps

Wed, 11 Sep 2024 00:00:00 +0000

Over the course of my career I spent a lot of time optimising and automating Build Farms, since Team Foundation Server 2008. I remember the first time I saw the first bits of what are now Pipelines as Code at the MVP Summit as well as when I had access to an early alpha version just after Christmas a fair few years ago…shipping has always been at the core of what I’ve done.

Needless to say, I worked on substantial Build Farms, including replicating the seamless experience Hosted Build Agents provide in my clients’ cloud estates. A lot of effort went into creating and customising Virtual Machine Scale Sets, Kubernetes clusters, Packer images, etc.

However if you don’t want to do that and you need to have your own Build Farm… the answer is Managed DevOps Pools. I spent some time working on them and I am pretty impressed.

First configuration

I ran through the Azure Portal to have an idea of how to configure a MDP and what level of flexibility you have, and it’s a lot.

To begin with, you have a dependency with Dev Center but that’s about it. Very interestingly, you can configure the Agent size right away and you can select either the Microsoft images, Marketplace images or (most importantly!) your Azure images.

The next crucial item is your Pool behaviour. These Azure resources will be deployed in a secure Microsoft subscription, and will be exclusively for you. However these will incur cost if not used, so you have a lot of flexibility in defining your behaviours:

There is a lot of flexibility here, and we will cover this in the next section. Now onto the next big thing…

I cannot stress enough how much of a big deal this is. Dealing with the infrastructure requirements of network-injected Agents deployed at runtime with finicky DNS configurations (and more) is more often than not a significant headache to setup. MDP does this for you, seamlessly.

You can then select an additional data disk if needed:

Then you can start looking at how to connect this with Azure DevOps. It is really interesting. First of all, you can potentially share a Managed DevOps Pool with multiple organisations, if you want. You can also restrict provisioning and access to specific Team Projects. But most importantly, you can inherit permissions from the Team Project saving a lot of configuration effort if your Azure DevOps Organisation is following best practices. Brilliant.

My recommendations

You are still operating within the confines of an Azure subscription, so you cannot deploy a sheer amount of resources without having a high-enough quota for the SKU of VMs you want to run. If you disregard this, you will quickly end up with this error:

Do an exercise of right-sizing, and understand if and how many agents you can warm-up to keep your teams efficient. It is your infrastructure after all, albeit deployed in a different subscription. You will be billed for it eventually!

I would also recommend against leaving Standby Agent mode off coupled with with fresh agents at least during office hours (or your peak usage window), as it will add 2-5 minutes to the provisioning of each and every agent used for the execution of your jobs. Of course it enables significant savings in terms of consumption, but unless you are using these agents for very specific circumstances (e.g.: updating production, multi-tenant environments in audited releases with a strict Single Responsibility Principle enforced) there is little benefit in that and performance will suffer.

Compared to your Build Pools, you won’t have custom capabilities raised directly by your Agent into a Managed Build Pool. What you can do is set environments variables in your Custom Image, but you need to account for that when you build it, so it’s not straightforward.

Abstraction is acceleration

Sat, 17 Aug 2024 00:00:00 +0000

Something I see far too often is a simple yet foundational mistake: chasing innovation at all costs, for the sake of it, rather than thinking about the key fundamental issues we are yet to solve as an industry.

Shipping quality software is the most important thing, no matter how cool or boring the underlying technology is. This is by far the most important metric we have, and if you really want to get going on that you need to embrace a simple approach: abstraction is acceleration.

What do you mean?

The moment you start abstracting, you are moving complexity away from the narrow path of delivery and onto a different bucket. It does not mean removing it, but rather assessing it as a known quantity and treating it as an acknowledged factor.

Abstracting means removing yourself from the shackles of repetition for all the must-haves, so you can focus on doing what really matters for your project - it can be about infrastructure, application stacks, configuration, anything. It creates a runway which gives you the focus you need on solving the problem at hand, rather than being diverted onto different things which should be solved by now.

An example

A typical example of this is azd. Azure Developer CLI is a pretty advanced form of abstraction, which enormously simplifies developers’ life by aggregating well-known infrastructure, application code and configuration in a single package.

This package is consumed as-is, giving you certainty about the steps performed during deployment: bringing up the infrastructure (via Bicep or Terraform, pretty standard stuff!), deploying the application correctly, etc.

Also very importantly, it is independent from any form of orchestrator - all you have to do is to invoke azd up even if you do not populate the .azdo and .github folders. It creates a repeatable experience independent of the execution environment, which is a must nowadays for developers.

If instead you want to build your pipelines around it, these two folders are the place where you store them so that they are integrated in the package.

You only accelerate if you are transparent

Be careful of an easy fallacy: you do not accelerate anything if the whole thing is not transparent. Abstracting doesn’t mean “yeah submit a manifest and trust me on execution” in an API call, it means encapsulating a number of steps together in a pre-configured yet reviewable process.

The reason why azd is a good example is because you have everything aggregated, yet it’s nothing new or opaque: your Infrastructure as Code definitions, your application code, your CI/CD pipelines - they are just kept together by a simple conventio, however they are independent of each other.

Retry logic in Azure DevOps tasks

Wed, 14 Aug 2024 00:00:00 +0000

Large yet quiet update a couple of months ago in Azure DevOps! One of the most requested features finally hit availability - retry logic in all server tasks.

Every task that runs in a job with a stateful environment (e.g.: anything except agentless tasks) was already supported, however this is now extended to tasks invoking an external service. They will now have an available property named retryCountOnTaskFailure, which can ve used to set a number of retries once execution fails.

Imagine… you are performing an operation targeting a remote URL/system/etc, and you will be able to retry. It is extremely useful, especially when publishing new bits on Azure resources. It’s not by chance that the Microsoft documentation shows AzureFunction as a sample task supporting this!

Now, there is an important consideration to make: your task is not idempotent. Do not expect rollbacks or structured retries, only the task (and the external call) is retried in its entirety, not the job or stage. You still need to account for failures etc, however this simplifies your pipeline design if you are using tasks extensively.

Recent improvements in GitHub Advanced Security for Azure DevOps

Sun, 28 Jul 2024 00:00:00 +0000

Over the past few months a number of good updates were released on GitHub Advanced Security for Azure DevOps, I felt they went a touch under the radar! Let’s see what these are, there are a few key changes worth knowing.

Overall security overview

You now have a single pane of glass view of your security posture across the organisation, under Organisation Settings:

This is a quality of life improvement, however for large organisation it also allows an understanding of hotspots and coverage at a glance. Very useful!

Enhanced secrets scanning

Secrets scanning is now enhanced, able to detect different patterns compared to the original set of vendor patterns. These are non-provider specific (e.g.: connection strings and various private keys!) and are incredibly common sights in scans.

| New Pattern | |——————| ASP.NET Machine Key DER-endcoded Private Key Dynatrace Token GPG Credentials HTTP Request Headers JavaScript Web Token LinkedIn Credentials MongoDB Connection String MySQL/MariaDB Connection String PEM-encoded Private Key PGP Private Key PKCS12 Formatted Private Key PostgreSQL Connection String Putty Private Key RabbitMQ Credentials RSA Private Key SQL Server Connection String SSH PrivateKey OpenSshPrivateKey SSH PrivateKey GitHubSshPrivateKey URL Encoded Credentials

These are in addition to the long list of Provider Patterns already supported.

Automatic Agent preparation for CodeQL detection

I really like this one, especially if you roll it out in a decorator in a self-hosted Build Farm: you can now automatically setup an Agent with the CodeQL extension as part of the Initialize CodeQL task in a Pipeline:

This will save you the hassle of setting up the CodeQL tools upfront and maintaining them up to date.

Continuous assurance, why are you not doing it?

Thu, 20 Jun 2024 00:00:00 +0000

Baffling conversation today, and a bit of a blast from the past. Mega-massive client has issues with their immutable environments - technical and regulatory. The regulatory stuff is relatively easily to fix once the technology is in place, and the summary of the conversation was: what can you do to remediate, quickly?

The answer is obviously Continuous Assurance but… we will get there. You need a starting point.

Let’s ignore development environments, they should be ephemeral and deployable on the fly, and they weren’t. However in this case the issue is deeper: the client is unable to reliably replicate an environment from scratch, or at will, to create a new copy of a production environment because there is drift between the production, pre-production environments and the scripts used to deploy and configure.

It’s a serious matter, as you cannot guarantee testing integrity, you cannot ensure that the pre-production environment is actually configured as expected, an audit will not succeed, etc. What could you do here?

Ideally there should be a foundational set of automations doing this on the Landing Zone (look at AzTS), but if you are starting with dev-driven bottom-up approach, you can do this: besides the expected review of procedures, scripts, etc. the idea is to embed Continuous Assurance as the leftmost step in the deployment procedure so that any release will validate the environment state.

And this is where things are simple to start with… if you deployed your environment with a Terraform module, what do you have?

a state file!

Exactly. And if you are not using Terraform you can achieve something similar by refreshing (not rebuilding, they are immutable!) the environment every release, and ensuring a re-application of your configuration as the first step. It sounds incredibly simple, yet you would be surprised by how many times this detail is overlooked. Gotta go back to basics and remember the technologies we are using on a daily basis.

If you do not have a state file (ARM, Bicep, etc.) then the refresh process for an immutable environment will always start with the infrastructure and configuration refresh. There will always be things to take into account: you might need to backup/re-image/restore/etc an environment, or build an allocation mechanism for finite resources such as API interfaces, but implementing this from the ground-up will give you the confidence you need in your immutable environments.

Azure DevOps

Azure DevOps also gives you some strong accelerators for this, and they have been around for a long time! Environments Checks for example:

Alternatively, build a deployment strategy supporting this proces. A hint: preDeploy hooks are fundamental for this. Worst case scenario if you don’t want to use them, Azure Pipelines allows you to create stages with a few extra lines of code. I am yet to hear a convincing enough answer to why you are not using them 😂

GitHub Actions

GitHub Actions does not give you these facilities given it is a platform-level orchestrator, however it’s not the end of the world - you can easily build a sequential orchestration leveraging the needs attribute for a job:

preprod_refresh:
...

preprod_deploy:
    **needs: preprod_refresh**
    ...

This is flexible enough to perform any form of operation required for an environment refresh.

It’s simple stuff, really, and obviously it’s not the end of the topic, but rather the beginning. But following this will allow any team to put these in practice quickly in absence of a platform-wide Continuous Assurance facilitation.

Engineering ingenuity will always prevail

Mon, 22 Apr 2024 00:00:00 +0000

More a thought rather than anything else… however, if you are still trying to unnecessarily restrict your developers, think again.

But governance! Compliance! Regulators!

All valid points, which will inhevitably lead to the same conclusion - unnecessarily restricting developers will only cause them to circumvent your restrictions.

When I say unnecessarily restricting I don’t mean not allowing unfettered production access or similar, to the contrary.

I am of the opinion that anything non-production needs to be as streamlined and light touch as possible. If you are not allowing your developers space to experiment, try out new ideas, innovate and chart the future. Telling them that they cannot use a certain tool, or they need to strictly stick to the User Stories rather than recording spikes and explorations will lead to them getting around your limitations (before leaving for another organisation, that is).

Do you want an extreme example? Have you ever considered that an Azure DevOps Agent Pool is a free hosting service for pretty much anything a disgruntled developer might want to test? Even better - if you lock everything down client-side and then you let a developer use a Microsoft-hosted Pool you are giving said developer access to a serverless compute platform. How long would you think it’s going to take a good engineer building scripts running in pipelines that can be invoked via the Azure DevOps APIs? BYOA (the A stands for API 😊)

There are ways of constructively channelling developer creativity and ingenuity, in 2024 it’s not just a nice to have - it’s very much a requirement to let your developers be developers.

What is the difference between Defender for DevOps and GitHub Advanced Security?

Fri, 19 Jan 2024 00:00:00 +0000

Very interesting question the other day:

What is the difference between Defender for DevOps and GitHub Advanced Security?

The answer is simple yet not clear-cut. Let me get there.

Defender for DevOps

Defender for DevOps is part of Azure Defender - the Cloud Security Posture Management tool for Azure and beyond. It can connect with GitHub and Azure DevOps repositories, and it provides code scanning vulnerabilities, security exposure alerts and supply chain management capabilities.

GitHub Advanced Security

Regardless of the target platform (GitHub or Azure DevOps), GitHub Advanced Security is a tool designed to integrate with your development platform and help your developers shift security left. It provides code scanning vulnerabilities, security exposure alerts and supply chain management capabilities.

The key difference

Defender for DevOps operates outside-in. It will inspect your codebases, it will raise alerts and will provide recommentations. It is designed to provide data points to consume at enterprise platform level.

GitHub Advanced Security does the same, however tightly integrated with the development platform, meaning you can integrate it with your development workflows. It is not just a surfacing and aggregation tool - it also provides proactive help to the developers.

An example

A developer tries to commit an Azure Storage Account SAS Key into the Git repository.

Defender for Cloud will only identify it after it goes through a CI/CD pipeline which uses the CredScan task (so the leak will be contained to the code repo and the platform admins or owners will receive an alert), GitHub Advanced Security will simply not allow you to commit the secret.

Redeployments should not be difficult

Sun, 07 Jan 2024 00:00:00 +0000

It’s a topic that comes up fairly frequently with many of my clients - why are redeployments unexpectedly difficult?

Now that DevOps is as pervasive as it’s ever been, people are (rightly so if you ask me) trying to do as many things as Code. It’s a testament to how the industry is going in the right direction, however the reality many developers face is that initial deployments as Code are very easy, redeployments… less so.

More often than not, it’s simple stuff. For example, if you are relying on something as simple as a synchronous interaction with a system, all you might need is a form of retry logic to solve the problem.

Some other times, it’s more complex - your system might need a full-fledged set of activities which will inhevitably result in some downtime. The first thing to do here is to leverage features like Deployment Jobs in Azure DevOps or Environments in GitHub Actions.

Both are almost mandatory tools nowadays, because they expose functionalities you would otherwise need to build manually for quality of life. For example, in Azure DevOps you can inject tasks via decorators or create a canary deployment strategy with a single line of code. In GitHub Actions you have excellent concurrency management as well as cancel-in-progress, a brilliant feature which will automatically cancel anything in progress if you need higher priority against other workflows.

It’s then down to your technology stack and your architecture. These are unfortunately often overlooked, or straight-up impossible to achieve in brownfield enviroments, however there is a general tendency of overlooking papercuts and tolerating certain compromises.

For example, if you ask me… Zero-touch deployments are a must. Idempotency is a key factor. These should never be compromised upon. If you cannot achieve idempotency you should automatically fall back to Blue-Green deployments as a pattern, as you risk ending up with unusable enviroments. Blue-Green in this instance prevents you from losing a functioning environment, and with zero-touch deployments you can still rebuild an environment.

It takes a lot of effort to get to a real zero-touch, robust and resilient enterprise systems. However it does not take a lot to start or improve an existing situation.

The role of the Double Diamond in a modern engineering organisation

Wed, 25 Oct 2023 00:00:00 +0000

I had this in draft for a very long time, especially after a conversation with one of my clients… did you ever notice how the Double Diamond process principle applies perfectly to modern engineering organisations?

The Double Diamond is a standard description of the design process, created by the Design Council in 2005. It represents the most general and applicable visualisation of a typical exploration and resolution of a given issue, deconstructing the thought process and defining the journey one does to get to the final result.

Now…this applies, word-by-word, to what we do on a daily basis. Think about this: your teams need to undertake a certain effort. What would they do?

The first step is embarking on a discovery exercise. This is not a linear endeavour, but rather a wide and large collection of data points and information required in order to have a better understanding of what’s going to happen. You will start at high-level, and narrow down as needed.

All this information alone is pointless and potentially confusing. The teams will then start defining what actually needs to happen, and how. The end result of this is a (relatively) clear view of the required work to be carried out. It brings everyone on the same page and people can start their low-level processes.

The same cycle repeats between implementation and delivery. If you are a developer, you are going to implement things your way, however the Peer Review process will suggest changes which might or might not align with what you had in mind originally.

This is the reining-in of the divergence the first phases of the Double Diamond, and they are brought to an agreed, final state where all the parties are ready to either proceed or move on. The process itself never ends, it’s highly repeatable, and it always delivers the same outcome. You are in control of the accuracy and the level of agreement between the parties.

The Design Council distilled the following framework for applying the Double Diamond:

Discover. The first diamond helps people understand, rather than simply assume, what the problem is. It involves speaking to and spending time with people who are affected by the issues.

Define. The insight gathered from the discovery phase can help you to define the challenge in a different way.

Develop. The second diamond encourages people to give different answers to the clearly defined problem, seeking inspiration from elsewhere and co-designing with a range of different people.

Deliver. Delivery involves testing out different solutions at small-scale, rejecting those that will not work and improving the ones that will.

Does it sound familiar at all?

Inner Source in an enterprise, measurement is king

Tue, 03 Oct 2023 00:00:00 +0000

Back on the topic of inner source, we now need to look at how we define success. Measurement and the right metrics will tell you if you are going in the right direction, and given it’s an internal project this data is going to be priceless in order to understand what to do next.

Establish a good set of metrics

The consumer is the most important persona in this scenario, so it’s ever so critical to get the metrics right. Tracking everything is one thing, putting your reading glasses on and analysing this data will be another matter.

Track actual actions - a deployment being executed, an API being invoked, any material action which makes sense to collect from an interaction point of view. This excludes contributions - they would be tracked separately in the developer platform itself.

Focus on what you want to understand. Adoption comes in many ways, however ensure you can build a good view of how your product is used.

Track everything, only if it makes sense

Given it’s an internal project we are talking about, you can take some liberties when it comes to tracking adoption. This doesn’t mean collecting PIIs from your colleagues or scraping the organisation for how many times your code was cloned, but rather having a good granularity of events and interactions collected in total transparency.

It’s important to avoid getting swarmed with white noise. Getting a list of all git clone commands your users ran against a repository (for example) doesn’t make sense no matter how tempting it might sound. Someone could be cloning a repo to kick the tyres of your codebase, with no further usage. Build runners might be cloning your repo at pace because of several builds running in parallel. It is pointless.

However be systematic in tracking, user interaction data is what will elicit patterns of usage and potentially raise early signs of issues. Get good quality data.

Learn and iterate

You surely want to know who is using your stuff, and what is not going well or causing issues to your users. That would be the most important measurement you can take.

Once you have this adoption data, iterate quickly on it. Initially you will notice a sea of anomalies and more problems than progress - this is perfectly normal, you won’t get it right first time around. However over time (and Pull Requests) you will quickly be able to identify what is going as expected and what doesn’t.

This picture will allow you to get a better understanding of your consumer base and how your product is being (mis)used. Early detection of these things is pivotal to proactively engage, given a critical mass. Otherwise it’s all data fundamental for retrospective analysis.

Improve your environments with Azure Deployment Stacks

Wed, 26 Jul 2023 00:00:00 +0000

Are you doing anything like this?

If so, you should try Azure Deployment Stacks. The feature was released in Public Preview a few days ago, and it is definitely worth looking at it as soon as possible.

Azure Deployment Stacks simplifies the resource lifecycle in Azure, it essentially groups together multiple resources under the same stack, removing the overhead of dealing with dependent resources and also applying effective policies improving governance

The documentation is heavily oriented towards Bicep, however it definitely works with ARM templates as well. And it works really well.

These are very welcome - the Update behavior property mimics the ARM Deployment Mode, however taking the Stack into consideration. The Lock property is amazing, potentially putting anything under the Stack in a protected mode, simplifying governance and control. The rest is an unaltered deployment, via an az stack command. Redeployments take into account dependencies and the Lock property.

It is so simple it is mindblowing. Also… this considerably extends the usefulness of the Environments in Azure DevOps:

While it was true that you could have done that without Azure Deployment Stacks, you now have a repeatable, out-of-the-box command to create a 1:1 map between the Environment on the platform and the target environment in Azure.

Done at scale, this significantly simplifies the life of Platform Engineering teams.

Linked workflows with GitHub Actions

Thu, 20 Jul 2023 00:00:00 +0000

This is literally the simplest possible thing, however… I wanted a workflow to be triggered only on successful execution of another workflow in GitHub Actions. I thought it will take somewhat more than the single workflow_run keyword!

It is one of the many triggeres available under the on: condition, and it will link one or many workflows to a secondary workflow. Beware, it does not act as a logical AND.

I put together a simple example on my account, here, I hope this helps. It helped me, given I wanted exactly that feature!

Progress is not linear

Mon, 10 Jul 2023 00:00:00 +0000

Last Thursday I was greeted with the excellent news of my 14th year as a Microsoft MVP.
Thinking about it… 14 years is a long, long time, and my career evolved with it - from being an engineer to looking after almost two hundreds people and contributing to a sizeable business number. Who knows if I will get to 15, either. However the very good news led me to think about the idea of progress, for more than the usual 30 seconds…

In this industry there is one thing which is very clear, and it is something I find myself repeating to people on a very regular basis:

Progress is not linear

Especially in consulting, there is an unhealthy expectation that progress is linear: delivery, promotions, success. All in a straight line, with no allowed diversion from the supposed golden path. Reality is, however, much different.

If things were supposed to be linear, we would not be in a world of Cloud and AI. I wouldn’t see the people I helped grow reach the goals and targets they did. I would also not be writing this post, for the record.

Progress is a consequence of attempting to innovate, to change something. Sometimes it’s a refinement, a minor change which makes something good better. Some other times it’s a proper challenge to the status quo, a complete revamp of something or even better, a brand-new idea which has got no match. Usually the latter is the most common idea of progress, however never discount the former - quality of life is a big thing, and once an improvement gets tangible people will understand the reasons behind.

Stuff sometimes just works. Sometimes instead it takes some hammering and multiple attempts to get where you really want to get. The journey matters.

No more excuses with App Registrations in Azure DevOps

Mon, 24 Apr 2023 00:00:00 +0000

It’s not really news, however…you can now add App Registrations and Managed Identities as users in Azure DevOps.

They will cost you a licence, however there is one massive benefit in enterprise environments: you can stop manually managing Personal Access Tokens, and you single-handedly control granular access to your environment(s) via a single identity.

This is a game-changer, as you can finally stop spending time on handling PATs (monitoring them, sending reminders to owners, etc.) as well as worrying about unfettered access that might leak via a misused token.

Also, this also means you can now control anything in ~Azure Active Directory~ Entra and you can guarantee unattended or privileged access to singular entities with a single Service Principals in a bidirectional fashion on environments and organization.

Imagine…

An App Registration is the only identity allowed to perform operations more privileged than just Read, directly connected to Azure DevOps and completely managed in Entra.

This, for enterprise environments, is massive.

Inner Source in an enterprise, the role of testing

Tue, 28 Mar 2023 00:00:00 +0000

Driving back home tonight I thought it was about time I continued my series on Inner Source… now time to talk about testing. It is part of the model you must define for contributors as well as embedding it within the validation process the team will enforce. Let’s see how.

Testing for contributors

Demand extensive testing as part of your contributions. Testing must be both effortless and extensive, there is no getting around to that.
If a contribution is not thoroughly tested, it will automatically fail the validation process no matter what.

How would you define “testing”? Well, first of all you need to test the literal functionality you are delivering.
Unit testing, assertion-based testing, anything that defines how a single feature is tested is absolutely a must. The hard part comes when you need to test integration with other features or parts of the system. In case of an application, typical integration testing works fine - however consider scenario-based or environment-based testing in order to ensure the contribution doesn’t break any existing functionality. If you are running other forms of testing, remember to ensure they are clearly separated from each other.

Automating testing to validate contributions

This is where things get interesting - once your contribution is tested, it needs to be tested again during the review process. So it becomes about how rather than what. You need to ensure end-to-end execution without requiring a single finger being lifted - for all of the tests above. Running them as part of your build validation is key. And it takes time.

When designing a testing strategy for your product this is the second thing that will take most of your time (the consumption model would be the top one). If testing isn’t seamless, you lose out on contributions. If testing is excessive, the result would be the same.

It’s not necessarily about how long it takes to test, but rather how much effort it takes for someone to run end-to-end and deep testing suites. Getting this right will enable a lot of contributions.

Feature flags and configuration management - are they the same?

Sun, 22 Jan 2023 00:00:00 +0000

Recently I’ve been dabbling with Azure App Configuration - a very nice technology if you ask me, which allows you to build your applications or services leveraging dynamic exposure control, canary releases, etc.

I liked it so much that I spoke about that at the London Microsoft DevOps Meetup this month, with lots of follow-up questions. One of them was pretty tough!

Do you consider feature toggles and flags part of configuration management?

The answer is a strong yes. Feature flags, rings, etc. all rely on configuration items being retrieved.

It doesn’t really matter what they are…it’s very much up to you what you use them for: static consumption, environment setup, exposure segmentation. We briefly talked about how to get started with adoption - rather than getting started with a massive refactoring exercise, you can slap a legacy flag on everything already in production, and start building new segmented areas of your application. Or you can start extracting key values used by your application (a configuration string perhaps?) and move them to Azure App Configuration so you can control their lifecycle in an easier fashion.

What really matters though is the concept of having a centralised database for configuration values. It gives you more control on a single source of truth for key information used by your services, and you can also update that as part of your CI/CD pipelines in a structured way, without relying on files.

Extensions (1, 2) for Azure DevOps and GitHub make this very easy, and azure appconfig is the cli tool to use.

Defender for DevOps, or rather enterprise integration...

Fri, 14 Oct 2022 00:00:00 +0000

Great news at Ignite in the past few days. There is one I am particularly close to: Defender for DevOps.

There are a number of reasons I am excited for it, there is no denying! The most important one is because Defender for DevOps makes your development platform (either Azure DevOps or GitHub) front and centre when it comes to security integration with the rest of the organisation.

Let me explain: unless tightly integrated, development platforms tend to drift away from enterprise governance - shifting left is twice as hard if nobody outside the engineering department has got visibility of it. That’s when the complex integration journeys begin, products start popping up with no coherent vision, patched together by either custom code or flaky tools. Doing things right in this space is possible, however it’s harder and it requires way more guidance at a strategic level.

Enter Defender for DevOps - this is all it takes to get going:

You will need to authorise Defender via a Project Collection Administrator account:

And you will be done:

Now, a word of advice. Defender for DevOps is extremely dependent on the tenant the Azure DevOps organisation is connected to, and it is also a preview so a few niggles are to be expected.. If the tenants are not aligned, Defender will never be able to find the target organization, so bear it in mind when it comes to multi-tenant situations.

Should you ever need to switch tenant for an Azure DevOps organization, you can do that under the Azure Active Directory tab in the organisation settings, with the Switch Directory button. It is seamless, nothing is lost if the tenants are configured correctly:

The end result will be something like this:

The organisation is now connected and it will be populated. All is left to do now is to install the Microsoft Security DevOps extension, and you can start adding the relevant task (MicrosoftSecurityDevOps@1) to the pipelines you are interested in. Results!

There is obviously more to do and more potential features to use, however this gives you an idea of why I believe it is so important. It also opens the door to a unified Azure DevOps and GitHub developer platform for enterprise organizations - the steps to configure Defender are the same, all it changes is the use of a GitHub App rather than an Azure DevOps identity.

Inner Source in an enterprise, the contribution model

Wed, 28 Sep 2022 00:00:00 +0000

Finally the most important topic to cover: how to build a sustainable contribution model?

Inner Source is not just some code dropped somewhere so that anyone can use it. Inner Source is about enabling teams to evolve their codebases in an organic fashion, ensuring reuse and synergies wherever possible.

Decision making

Decision making is very simple in Inner Source: everything is transparent, automatic processes ensure quality, your governance is enforced by design and the consumers naturally align with the objectives of the project. The maintainer team will always be the one dealing with the vision and its transformation into execution, however every Inner Source project will always be transparent because everything happens in pure openness, for everyone.

In order to do that you need a usable process that allows anyone to get their changes to the main codebase without an excessive amount of friction.

Pull Requests!

You might suggest Pull Requests. Yes, they are part and parcel of the process, but before you get there you need a few extra items along the way. Also remember how documentation plays a key part, because it’s where you define the ground rules: branching strategy, baseline testing, rules for documentation, etc.

The importance of a package

What are you trying to achieve, exactly? In my past post I mentioned how important it is to make the end user experience simple enough so they can get going quickly.
If you want to do it you need to define what is your package, the artifact that the users will consume. It can be a repository, it can be a binary, anything will do as long as it is consumable.

Your package (or its content) will need to be versioned in predictable way. Semantic Versioning usually comes to the rescue, however you can also use a simpler version with just Major.minor as values. What really matters is using it right: it will be your contract with the consumers, so make sure to setup some solid ground rules as well as documentation to support that.

In my latest Inner Source project I settled on a code repository as a package, containing a number of versioned items. With the right documentation in tow users can use it in a simple and straightforward way, easily embedding it into their projects while at the same time ensuring upgrades remain seamless due to the nature of the repository.

Testing

Testing will be the most important step to establish when it comes to Inner Source contributions. Yes, there might be a test suite in the codebase, however you need to enforce its execution, together with some extra scans ensuring your quality levels.

The other side of the coin is that everything must be automated, no matter what. There is absolutely no reason for your quality bar to rrely on human intervention. If you cannot automate things, don’t do Inner Source or it will suck so much time out of your day.

I say that seriously: an Inner Source product (being open by default) requires a lot of attention, as much if not more than a traditional project, and it really needs a strong set of automations to remain smooth and lightweight. With every contribution there is a new opportunity, however there is also a sizeable risk of overseeing critical stuff. Automate your processes.

Am I mature enough for it?

Inner Source doesn’t happen overnight - it’s something that takes time to evolve, like every cultural change, you might try and fail a few times, however it’s not necessarily down to a single team or organisation. You might have full organisational backing and no contributors, or many contributors with no outlet for converging.

Remember to setup a vision for it. It can be speed, it can be reuse of code, it can be collaboration. As long as you have something you are striving for, Inner Source will help your organisation achieve it with the power of decades of Open Source development.

It is a mindset change that requires exercise and the right balance in place, otherwise it will quickly become overhead.

Inner Source in an enterprise, the consumption model

Tue, 27 Sep 2022 00:00:00 +0000

I wanted to talk about the contribution model first, however I felt it would be important to think about the users first. So after talking about the whys, it’s time to talk about one of the hows: how to consume an Inner Source project. How will your users consume your code? Why is it so important?

Documentation is your main enabler

The barrier of entry needs to be lowest than ever. It might be a README.md file, a SharePoint or Confluence page, a Wiki, what really matters is that users can get going as soon as possible.

Low entry barrier doesn’t mean no or little documentation. To the contrary, the more the better. What I found really intuitive is a mix of high-level, getting started documents coupled with deep, low-level pieces detailing every possible parameter, scenario or functionality. An Inner Source project is a product at heart, so it needs to be treated as such.

Consider automatic documentation generation - it makes your life so much easier. Docs as code also ensures automatic compliance with your contribution model, making it part of a contribution. Technologies like Jinja2 or GitHub Pages make writing documentation so much easier and straightforward. Worst case scenario, a code wiki in Azure DevOps does wonders!

Make it easy to use

Whatever you are building, make sure to bundle an automatic build script at a minimum. Not just a detailed, step-by-step guide, but rather a one-click-script. A pipeline would be even better. You need to make sure your users will be able to get going with a single interaction, no matter what.

If you are developing code to be used alongside other code, I would strongly recommend an approach where your code repository becomes a package - doing that means that everybody will get immediate benefit from updates, and it doesn’t require any form of update besides getting it.

For example, Azure DevOps has a dedicated YAML keyword (resources) which allows you exactly that:

resources:
  repositories:
  - repository: innersource
    type: git
    name: InnerSourceProject/tool

steps:
- checkout: self
- checkout: innersource
...

Your pipeline automatically consumes the latest version of the Inner Source code, with no effort. Easy.

Why am I pushing so much for it? Well, it’s about one of the main differences compared to Open Source development - you have a fundamentally different audience compared to the outside world.
Yes, many people will be as passionate and engaged, however some will be less interested and maybe even forced to use your tool. Not everybody, unfortunately, cares. By making the consumption experience as seamless as possible you are removing a number of potential support questions to field, and the first contact for someone who is not necessarily excited about the codebase will as positive as it comes.

Try to bring them along

Don’t forget to include an easy way for a user to engage with the maintainer team, either to request something new or to report a bug, and if they had a smooth and easy experience chances are they would be interested in contributing and enhancing your product with their features! So ensure your documentation covers the contribution model, and you will hopefully be able to get contributions out of them!

Inner Source in an enterprise, how to get started

Tue, 20 Sep 2022 00:00:00 +0000

I want to talk about a project that took a year and a half to get to full speed, now bringing an incredible amount of value to one of my clients: an Inner Source project.

Before discussing the actual steps required to get started, get comfortable with the definition of Inner Source:

Open source development practices brought within the corporate boundaries

No, I am not going to quote Wikipedia for once - just look at how messed-up the Inner Source page is! And no, I am not referring to the content…

So, open source practices within an organisation. The first question to ask is “why?”

How to get started

Before you write a line of code you need to start drumming-up interest for your project, which is where you will start assembling contributor teams and external members who provide extra value on top of the core maintainer team. Even users count!

Then let’s address the elephant in the room - why should someone contribute? How are you planning to make it work? Define the vision. Keep goals simple. All you need is removing silos and facilitating communication, after all. I cannot emphasise it enough: without a transparent way for people to see everything and have access to everything Inner Source won’t work.

No matter the age of the codebase you need to setup some simple ground rules: how to submit ideas, contribute, review. Make sure roles are loosely defined (e.g.: maintainer team, external contributor, etc.), followed by a definition of the process to follow. It’s not about the details as much as the perceived level of overhead - the lesser the better.

If you have at least one clear set of contributors and a core team you are ready to start.

The reasons behind an Inner Source model

Whoever proposes to use Inner Source, they need to clearly explain the reasons why they want to use it. It’s not as simple as publishing code somewhere and let users fork the repository. Doing that means dumping code in a skip.

Inner Source at its core is a variation of Open source, adapted to the world of corporate (i.e. internal) software development. The mechanisms do not change, however the conceptual pillars require a degree of change for any corporate culture.

In theory anyone can make changes, fork, adapt and enhance the codebase - it’s open by default. You build it (literally!), you run it. It’s not a process governed by change management, unless you want it to be, however losing its original meaning.

So why Inner Source? It’s usually down to two reasons: speed or quality.

With Inner Source, speed is a well-known quantity. You merge a change, it becomes available to any user. Decision-making happens at the speed of a Pull Request and it allows for an easier, faster cadence of updates.

More often than not though, the main reason is quality. Given a codebase, Inner Source raises the quality bar by the virtue of the collective review process. Code reuse means better maintainability across the organisation, as well as a leaner experience for any developer Also, it allows contributors from outside a designated core team, meaning a plurality of ideas will lead to better code.

Eventually there is also a nice side effect: clarity of relationships between development team(s) and outside actors, including non-technical stakeholders.

What’s next?

Tools. Next time though.

Where Supply Chain Management really matters

Wed, 06 Apr 2022 00:00:00 +0000

If you use GitHub you are surely used to this:

Nowadays we are starting to take supply chain management for granted. Unfortunately it is a tendency as an industry - instead of focusing on remediating and improving our existing code, we treat it as a nuisance only focusing on what’s next.

However new, shiny code doesn’t really matter if you are reading this, and if you are running a full-fledged DevOps practice you will quickly realise that there is so much work fo do when it comes to introducing Supply Chain Management in an organisation. If you are using GitHub then great, Dependabot gives you a great headstart by integrating with the platform and continuously scanning your code. However, what if you use something else?

There are so many tools on the market for this: Whitesource, Snyk, etc. Even SonarQube can do Software Composition Analysis (another name for Supply Chain Management) via an OWASP plugin. It goes to show how important this topic is and how much choice there is if you want to make things right.

The reason why it is really important is because your legacy code is most likely running in production. Like the vast majority of us, I have a number of repositories with legacy code. This sample application was written in .NET Core 1.1, and it’s been last updated in October 2017. If you never ran anything like Snyk or Whitesource, you will naturally find something akin to this state.

Some of these vulnerabilities can be easily fixed by a version bump, however others would require a complete runtime change, a migration, etc. A Supply Chain Management tool combined with your Engineering Platform will go a long way in making sure that your organisation remains sustainable.

Personally, I really like Snyk. I used all of the tools above for years, and as of today it is the one that in my view gives the most comprehensive experience with the least amount of friction. You can set it up in minutes, and if you are targeting Azure DevOps it gives you so much power directly into the platform.

I really found beneficial having an easy way of raising Pull Requests from outside Team Projects so that development teams can benefit from them. It is also quite smart in understanding what can be easily fixed and what can’t, as well as giving you so much information about the issues at hand:

In my case above there is little point in raising a PR this way, however with more recent systems it provides you with an easy way of approaching a remediation without involving too intensive efforts. Of course every time you look at something running in production you might not be able to just update the code dependencies, but that’s a story for another day…

Solving an identity crisis in an Azure and DevOps world

Mon, 28 Feb 2022 00:00:00 +0000

So… identities. A cornerstone of any cloud platform and essential in a DevOps world. However I end up talking about these on a daily basis in the Azure space, so I hope this post can act as a cheat sheat for my readers! One disclaimer though: I am not an identity expert, so I might use some simplification here and there.

Where it gets messy

There are two kind of identities we are interested in: interactive and unattended.

The problem users face is that one of these two categories is actually more complex than it should be - the unattended one. There are several distinctions to make, however let’s clear out what identities are first…

Interactive v unattended

As you may guess, an interactive identity is anything associated to an actual user: name.surname@tenant.com, DOMAIN\namesurname, or anything else that refers back to an actual carbon-based life form (sorry Andy, it makes me chuckle every time!).

The same is true for something like a PAT token in Azure DevOps too. Yes, it’s a token rather than a username+password combination, however it still brings authentication back to an interactive user, hence it is an interactive user.

It’s worth remembering that these are the worst type of users to deal with in a hyperautomated setup, and you should not try to use them in any form of automation unless absolutely necessary. Passwords will expire, 2FA will kick-in, etc. They are unreliable when it comes to automatic interactions.

An unattended identity is anything that is registered in the directory system however it doesn’t necessarily expose a password, and it is still part of the Role Based Access Control model that ~any cloud provider~ Azure uses.

Managed Identities

A Managed Identity is a resource type in Azure. You can create a user-assigned Managed Identity or a system-assigned Managed Identity.

The difference between the two is in the lifecycle - a user-assigned one is a standalone resource type, and you physically control it. Unless you delete it, it exists. You can assign it to different resources, and explicitly group together multiple resources with it.

A system-assigned Managed Identity instead is unique to, and tied to the resource it’s part of - once the resource is deleted, the Identity goes too.

Application Registations and Enterprise Applications

This is the most common identity-related question I reply to all the time - argh!

What is an Enterprise Application?
How about an Application Registration?
Isn’t it a Service Principal?

So, let’s make it clear - all of these live in Azure Active Directory.

An Enterprise Application is…an application. Any application registered in AAD, from any tenant. Azure DevOps? Enterprise Application. ServiceNow? Enterprise Application. Teams? Enterprise Application. It’s an entity that represents an application across one or multiple AAD tenants.

An Application Registration is the representation of an application you own (yours, custom) in Active Directory. It’s also tied to an Enterprise Application - because it is an application.

The difference? The Application Registration contains all the application settings (authentication, secrets, API permissions, etc.), while the Enterprise Application is used for RBAC and it is the actual entity used for authentication.

What is a Service Principal?

Service Principals are often used as synonyms for Application Registrations (because that’s where the keys/secrets/passwords are), however it is wrong. The Service Principal is hosted in the Enterprise Application, and it is what you actually use for permissions.

The confusion is annoying though - let’s say you create a Service Connection in Azure DevOps. What happens there?

Ah, it says Service Principal! Brilliant, that’s it then! Even the link says that!

However if you click that link you will end-up in an Application Registration blade of the Azure Portal.

The Application Registration and the Enterprise Application will have the same Application ID, however different Object ID in Active Directory.

They are two entities for the same thing.

What do I use in DevOps?

All of them. Managed Identities represent resources, Enterprise Applications any form of service or application requiring an identification and an Application Registration is what you use to generate secrets and contexts of applications you own.

PAT options for Azure DevOps organisations

Sun, 30 Jan 2022 00:00:00 +0000

This was a fairly unknown feature, however it’s a very important one when it comes to security in a large-scale Azure DevOps deployment…

As I am sure you know, PAT tokens are secrets directly bound to an identity - user-managed, easy to consume and very valuable for automations (we’ll talk more about all things identity in the short future). These tokens represent a user, and they can be scoped to the most granular level of access. What unfortunately happens though, is that users will create a full-scope Access Token for the sake of convenience - often with the longest expiration possible.

This is an incredibly poor security stance, as secrets can leak and they can be a major risk. However I was really please to find out that Azure DevOps allows you to configure three key options at an organisation level:

Enforcing an organisation to scope the PAT onto
Enforcing a specific scope rather than Full Access
Enforcing a defined lifespan

These three policies are really easy to configure yet so powerful - you can enable them, and also provide a whitelisted set of users and groups to exclude, for any reason you might have.

It’s worth mentioning that some APIs are not consumable if you are not using a full-scoped PAT. Microsoft clearly calls this out in their documentation, and hopefully they will provide a list so you know when to whitelist a user.

The most useful tool in Inner Source

Tue, 18 Jan 2022 00:00:00 +0000

I introduced Inner Source to my current client roughly 18 months ago. It was a big change for a massive 100,000 employees organisation, used to somewhat traditional development practices (not Waterfall - I would have flatout refused!) however quite curious and willing to try out innovative ideas.

The journey continues uninterrupted, there is always so much going on and the contributions are quite steady - Azure DevOps really shines with Boards, and teams are fully onboard.

There is however one tool (if you want to call it as such…) that really helped us along the way. It’s not a technology tool, a stack, or even a script, but something rather simpler…

Immutable commits

Defining immutable commits is like defining a package. You know what it is, what it contains, its version. We however work with Git repositories, so the definition becomes cloudy: what would be your package? Adding further complexity to the question, we ship a product available to everyone inside the organisation, and the contribution model needs to fit a Git consumption scenario quite easily.

In our case we settled on the hash of the commit. It’s the option with the lowest friction, and it is a common denominator for everyone. The idea is simple: if you want to contribute something, you work in your own fork. There you can develop however you like (within the framework), however you need to end up in a situation where you have unique commits to push. This is accomplished by Pull Requests.

These commits are then pushed to the main repository, where they get integrated and eventually made available to the consumers. Simple, right?

The idea behind it

While now the core development team works on the main repository themselves, contributors need to ensure they are not pushing commits with duiqsrbf0quibwri0pufb as a commit message (or worse!). We also need them to clearly label what they are pushing, and this helps a lot in narrowing down issues down the line.

Let’s take this as an example:

These can all be external contributions. How? Well, like this:

The commit hashes are the same across the board, despite being different repositories and different team projects altogether! What really matters is that Core.Department2 ended up pushing a bunch of validated, reviewed commits to Core like packages.

How to put this into practice

The implementation can be achieved with any system supporting Pull Requests. When you accept any external contribution using this model you need to ensure the PRs are closed enforcing rebase and fast-forward as a merge strategy:

This ensures that only commits really ready-to-go (imagine a staging area) can be pushed along. This also doesn’t mean that you need to have one commit per PR, or duplicate effort - the name of the PR might be Merged PR 58: Updated README.md, however that contained the top two commits you see in the history!

Enforce it

It’s all down to good practice. Like I said, the core development team works on the repository directly so they can squash merge all the changes, while the external contributors have to go through their own fork. This is enforced via a simple Branch Policy in Azure Repos:

If you want to do the same in GitHub, you need to look at this setting in the repository Options, under Settings:

Finally, we used to have the core development team follow the same process as the contributors for over a year. Same game, same rules for everyone. The reason why we moved away from it was simply down to the volume of changes and features delivered, making it slightly impractical.

If, however, the difference in volume is not massive or there is no core development team then I would recommend going for the same standard across the various teams and remove the squash merge option.

Triggering the butterfly effect

Fri, 07 Jan 2022 00:00:00 +0000

An interesting conversation came up a few weeks ago at a conference panel: there is definitely one strong misconception when it comes to Software Engineering, DevOps and transformations in general - if you want to start, you need a number of things which might seem necessary.

That’s why I strongly disagree. The reality is that these things might actually be overkill, useless or even damaging to your business. In order to start, you need a catalyst. And for the catalyst to be effective, you need to bring tangible value straight-away.

What does it take to trigger the butterfly effect?

Think about it, for any of the topics above: what do you need to get going? Anyone you ask will give you a different answer, and it usually relies on a technology, a certain flavour of a methodology or even worse a tool. Some will even throw in culture, for good measure. However I disagree. It’s not just that. These are all consequences.

Keep things simple. You want to start with DevOps? Don’t think about a tool, or any other substantial change that will bring you to a standstill. The business needs to keep going! Instead, start by introducing automation.

Automate something, and incrementally go from there. Scripting does wonders. Once the automation is in place it will reduce the amount of time a certain operation takes (compared to a manual interaction) and will also reduce the risk of errors. CI/CD is an excellent starting point, but it isn’t necessarily the only one. If you already have CI/CD in place but you want to go further, look into automating configurations, reducing manual maintenance actions, etc.

Long story short, the goal is to enable you and your team to re-invest that time you are saving into further automations and other (potentially bigger) changes. This is the butterfly effect of DevOps.

Why I took a break from blogging

Fri, 10 Dec 2021 00:00:00 +0000

For the past fifteen years I’ve been blogging with regularity, at least once a month. This blog starts with entries from 2012, however I’ve been blogging for far longer.

I just needed a bit of a break, as this year has been particularly tough: the second year of the COVID-19 pandemic, so much going on at work and even more outside of it.

Work has been a source of continuous inspiration and kept me fed with challenges and motivation - the type of work I do brings me ever closer to the core business problems we all aim to solve, and one of my core goals is people development. I love working on people’s development and being able to steer organisations to the best possible path they can take.

Community didn’t take a backseat - I am planning to restart the London Microsoft DevOps Meetup with Tarun, and we are already planning for GDBC 2022. I also managed to (virtually) participate to several events this year, and spending time with the folks organising DDD has been as amazing as always. I slowed down a fair bit, but I didn’t lose touch with the amazing technical communities worldwide. Events have been rescheduled, cancelled, moved - however stuff got done!

Outside of work, again so much going on. Who is close know how much happened in 2021, and how much effort went into all of these things.

The result is that, unfortunately, blogging slowed down. I had way less time to do so, and most importantly I just didn’t have the energy to dedicate myself to the amount of experimentation and writing I used to do, as a result for the past three months I didn’t publish anything.

Things will hopefully change, with a couple of big holidays coming up (to recharge!) and a number of things already listed in my neverending notebook. You will soon hear back from me, and I will start touching on some less beaten topics in the software engineering world. But for now, I am enjoying a little break :-)

Why GitHub Issues is different

Fri, 24 Sep 2021 00:00:00 +0000

The point of this post is not to do a walkthrough of the new GitHub Issues experience (it’s awesome by the way!), but rather to think about what I believe is the reason and the ethos of the feature. It was inspired by a conversation with colleagues which I believe was worth sharing.

As developers, we got used to the sticky note experience - the requirements you are aware of are summarised with a sticky note, with a title, and no other information is brought to the forefront of what you see as the first impact. Hence the Azure Boards experience, in a nutshell, where the complexity of the requirement sits a level below view.

The reason why I like Azure Boards so much is that you are just one level away from all the details, compared with other tools. However, I like it because I am used to go back and forth between backlogs, teams and projects. This experience acts as a common denominator across projects and organisations, with an agreement saying that if I need more information about an item I can click on it and get it all.

Brilliant, but not really practical from an individual perspective. Why? Because of the context switch between the overall status and the actual progress. If you want to switch from a board to a list (the backlog?) you literally need to move from a place to the other. Context switch is expensive in both computer programming and human behaviour.

GitHub Issues doesn’t do that - you can customise a tabular view with all the key information:

And by clicking on the arrow you can immediately switch to a board view:

which will contain the same information in a different visualisation, without forcing you to context switch between the two:

Now, there is no better way. GitHub Issues gives you something different, which you can customise and integrate with other tools. Some people might like it in a way, some others might prefer another one.

On repeatable automations

Wed, 04 Aug 2021 00:00:00 +0000

Automations are the cornerstone of DevOps, and they allow for a substantial increase in speed and quality.

I say this at least on a monthly basis, which is good because it means there is demand for adopting automations. The industry pushes towards the trend of automating everything, and I am sure your technical feed is no stranger to advocates of this discipline. It’s great, as this momentum drives collective improvements.

What we usually do not see is, however, what comes next. You should not just automate, you should automate in a repeatable fashion. Let’s take a look at how you can get there.

Repeatable automations - what are you talking about?

An automation must be repeatable. An automation is not just a script. An automation is something you can run any time, and it is going to return a predictable output at all times.

Let’s take an example familiar to everyone: creating a resource, whatever that is, in a Resource Group. It’s a simple command at the end of the day:

Create-MyCoolResource -ResourceGroup $resourceGroup

Now you want to automate it - very good. You (and I) will likely end up running something akin to:

param(
    $resourceGroup
)
Create-MyCoolResource -ResourceGroup $resourceGroup

A simple input of a Resource Group name and off you go with your automation. Nice. The next logical step is to execute this command via a form of unattended environment, like inside an Azure Pipeline or a GitHub Actions workflow, possibly backed by a Service Principal.

However, this will fail 100% of the times if you run the same command against a multi-subscription environment: if your Resource Group is not in the default subscription for the identity running it, the command will not be successful. Think about the Service Connections in Azure DevOps - they are either scoped to a default Subscription or a default Resource Group, then whatever happens behind the scenes is handled in Azure.

So what will you do here? Well, easy enough, you will add a parameter to request an explicit Subscription ID:

param(
    $resourceGroup,
    $subscriptionId
)
Create-MyCoolResource -ResourceGroup $resourceGroup -SubscriptionId $subscriptionId

Doing this ensures that as long as the identity running the command is authorised, it will be able to reach the right subscription and perform Create-MyCoolResource. Thinking upfront about these situations requires awareness and adds very little work to an otherwise simple process, however doing it pays dividends longer term.

Pre-empting your context and validating your inputs

Following on from the above example, how can we make sure we are covered from unexpected situations where a command will not support something like an explicit SubscriptionId parameter? It’s critical to think about that scenario, because you might have to integrate your new script with some other existing code, or utilities, which might not behave as expected.

Step back, and think about where you are executing this script. How do you ensure you are safe from the condition? Simple: add an explicit context setup!

param(
    $resourceGroup,
    $subscriptionId
)

Set-AzContext -Subscription $subscriptionId

Create-MyCoolResource -ResourceGroup $resourceGroup -SubscriptionId $subscriptionId

This ensures that whatever you do, you are covered by the context being set at the earliest possible stage.

Then obviously, you can do more: making your parameters mandatory and type-validated so you are prevented from entering useless inputs, as well as adding some good old try-catch and text outputs to make sure messages and errors are surfaced nicely:

param(
    [Mandatory]
    [string]$resourceGroup,
    [Mandatory]
    [string]$subscriptionId
)

Set-AzContext -Subscription $subscriptionId

try {
    Create-MyCoolResource -ResourceGroup $resourceGroup -SubscriptionId $subscriptionId
    Write-Host "Resource created"
} 
catch {
    Write-Host "An error occurred"
    Write-Host $_
}

Retry wherever possible

Call me biased if you like, but I am a big fan of retry logic. It’s simple, and provides so much support in fully unattended situations. Retry logic acts as a safety net for networking and platform issues, ensuring your commands will be automatically rerun in the correct fashion.

In our case, how does it look like?

param(
    [Mandatory]
    [string]$resourceGroup,
    [Mandatory]
    [string]$subscriptionId
)

Set-AzContext -Subscription $subscriptionId

$count = 0
do {
    try {
        Create-MyCoolResource -ResourceGroup $resourceGroup -SubscriptionId $subscriptionId
        Write-Host "Resource created"
        break
    } 
    catch {
        $retry++
        Write-Host "An error occurred"
        Write-Host $_
    }
} while ($retry -lt 3)

A very simple retry logic here re-runs the command for three times if an error is caught-up, otherwise the resource is created without further ado. This is a very powerful tool as it gives you a way of not wasting time on platform-level issues (a transient network issue can derail processes, let me tell you!) while still giving you a huge amount of control.

You can also use this approach combined with some waiting time, so that you can actually rule out external environmental issues like service unavailability.

Azure DevOps Token Scoping

Tue, 20 Jul 2021 00:00:00 +0000

Working for a client that does large scale enterprise development and Inner Source means we run into this fairly often with new projects consuming different resources in a pipeline:

It is a well documented behaviour - it’s down to how Azure DevOps authorises consumption when there are permissions in place. In a nutshell, it’s all down to this setting, in either the Team Project or the Organisation:

Now, why does it happen? The reason is pretty simple - every pipeline is authorised with a dedicated token, and on first run it needs an explicit validation if the above settings are on.

What is best practice?

The answer to which is the best approach to use here is the classic it depends. Do you want any user in your Azure DevOps organisation to be able to get to any repository with a checkout step? If so disabling the settings above might be the best possible option.

Are you working with multiple parties where you need actual segregation? Enforce them at organisational level in that case.

Unpublishing your latest Git commit

Fri, 18 Jun 2021 00:00:00 +0000

Sometimes it happens - you pushed a commit to a remote repository and you need to remove it, in a rush and without changing the repository’s history.

There are so many ways of doing that, but one reliable and easy way I found is this:

git push <remote> +<hash>^:<branch>

This will force push a removal, for a commit hash, on a certain branch, of a certain remote.

I wrote it this way because it is very easy to explain :-) It’s also easy to automate because it targets a single commit.

Just roll-up your backlogs!

Sun, 02 May 2021 00:00:00 +0000

I know - it’s 2021 and Agile methodologies should be used as standard. They are, for the most part, but every now and then I find myself talking to clients that would like to see a proliferation of projects (Team Projects in Azure DevOps if you like) to keep their teams in the dark about their peers, while at the same time they want to have a portfolio-level view of everything happening at any given time.

I want a pretty cake, I want to devour it, and I want the cake to remain pretty.

That is not just a pipe dream, but it’s rather wrong too. Think about it: do you want to move in the direction of obscure boundaries with teams, whilst the whole industry is going in the opposite direction?

The answer is no, of course. These questions are not intentionally malicious - to the contrary, it’s just a reflection of the comfort zone of an organisation. Moving on is always feasible (being willing of course), and more often than not once the new normal is demonstrated people are very keen to get on with it.

Take the above example: team focus and portfolio management at the same time. How can you do that, effectively, and with minimal friction?

Take Azure DevOps for example. Don’t create a sprawling mass of Team Projects in an organisation. Unless you have regulatory reasons to keep things physically separate (and even then, we should still have a chat), you can easily live with a single Team Project.

All it takes is a couple of settings to iron out to get what you want:

the org-level team will contain all your individual teams (and each individual team will have an Area assigned to them)
set the org-level Areas setting to include all the subareas from the root one

Job done. Each team will be able to access their backlog, as well as being able to link their work to the shared Features/Epics that you use for shared priorities. This also enables Delivery Plans to be easily created, and portfolio management becomes a manageable task without introducing friction.

Why complicate things if all you need is already out there? Elegance and pragmatism always go a long way.

Template extensions in Azure Pipelines

Tue, 23 Feb 2021 00:00:00 +0000

As part of a project I am working on we have a strong usage of Pipelines templates, and the consumption chain is nested across multiple repositories.

In my situation, let’s say we have a Core repository, that contains a set of baseline assets. There will be another repository in a Department Team Project, aggregating multiple assets from Core and offering them as templates for broader consumption. Which will bring you to a Consumer which will use these templates (and potentially do more things).

The first step is very easy: you define your asset.yml pipeline in the Core Team Project, which does a number of things. That pipeline is then invoked by a template.yml in the Department Team Project:

resources:
  repositories:
    - repository: Assets
      type: git
      name: 'Core/Core'

steps:
- template: asset.yml@Assets
  parameters:
    param: ["a", "b"]

This is pretty straightforward. But what if you want to consume your template.yml elsewhere, as a nested template? You cannot do the same as between Core and Department, because it will complain about the pipeline being invalid with an unexpected resources value.

The answer is in the extends keyword: it allows a template to be used as-is, and extended as needed:

resources:
  repositories:
    - repository: Templates
      type: git
      name: 'Department/Department'

extends:
  template: template.yml@Templates

With that I am going to be able to consume the templates in the way I expected.

Why I believe Azure Pipelines is still the best orchestrator for Azure Kubernetes Services

Sun, 07 Feb 2021 00:00:00 +0000

Small confession to make: I don’t get excited by pure technology anymore.

Gone are the pioneeristic days of getting something together, as in 2021 we now have such a wealth of technologies, frameworks and documentation that makes it a degree of magnitude easier to do anything compared to even just five years ago.

Today I spent some time on a pet project of mine on Azure Kubernetes Services, and taking a step back from the code I just realised how much work happens behind the scenes and how easy Azure Pipelines makes it for any AKS user to not only setup the CI/CD process, but also to maintain extreme control while still having accelerators and automations doing things for you.

Once the Service Principal is configured with the appropriate permissions (in the real world you usually do :-) ) you can use the Service Connection anywhere within your YAML pipeline - that is extremely handy, and it also enables appropriate usage of Environments:

  jobs:
  - deployment: Deploy
    displayName: Deploy
    pool:
      vmImage: 'ubuntu-latest'
    environment: 'AKS'
    strategy:
      runOnce:
        deploy:
          steps:
          - task: KubernetesManifest@0
            displayName: Create imagePullSecret
            inputs:
              action: 'createSecret'
              kubernetesServiceConnection: 'dev-aks-default'
              namespace: 'default'
              secretType: 'dockerRegistry'
              secretName: '$(imagePullSecret)'
              dockerRegistryEndpoint: '$(dockerRegistryServiceConnection)'
              
          - task: KubernetesManifest@0
            displayName: Deploy to Kubernetes cluster
            inputs:
              action: 'deploy'
              kubernetesServiceConnection: 'dev-aks-default'
              namespace: 'default'
              manifests: |
                $(Pipeline.Workspace)/manifests/deployment.yml
                $(Pipeline.Workspace)/manifests/service.yml
              containers: '$(containerRegistry)/$(imageRepository):$(tag)'
              imagePullSecrets: '$(imagePullSecret)'

That’s where thing get interesting, as you not only get access to a fully traceable set of information about your deployments, but also to key information about the health of the cluster and the related YAML configuration files in actual use.

You can even peek into the actual cluster application logs!

It’s transparent, yet it provides so much value directly within the Pipelines hub. Now, this might be me being over-enthusiastic, but a good facilitator is always welcome and in this case Azure Pipelines provides a user experience I still consider second to none!

CI and CD with GitHub Actions - what is different from Azure Pipelines?

Sun, 31 Jan 2021 00:00:00 +0000

Eventually, I did it - I tried an end-to-end CI/CD workflow exclusively on GitHub Actions. Talking about details, I moved my end-to-end demo of an ASP.NET Core application deployed to an Azure Web App (with Deployment Slots), with MSDeploy packaging and infrastructure deployment via Azure Resource Manager.

Nothing really complex or bleeding edge, but susprisingly commonplace in many organisations. It was neither difficult nor totally plain-saling, so I thought about putting together what I found interesting. If you need one takeaway though, it better be this: YAML is an investment for you. The sooner you are comfortable with it, the sooner you can tackle pretty much anything!

Look into the environment variables before you start

Like Azure Pipelines, GitHub Actions has its own set of environment variables. Look into them and make sure it’s all clear for you - you’ll need them!

One to remember: GITHUB_WORKSPACE. It is the folder where your repository is downloaded! In order to use that you need to surround it like that:

...
    template: ${{ github.workspace }}/src/IaC/template.json
...

GitHub Actions is an agnostic platform

GitHub Actions does not have any specific connection or accelerator to any target platform. While this is a big advantage in several situations, it can take you off-guard if you try to move from an orchestrator with service connections like Azure Pipelines.

If you like me are targeting Azure, you are going to use the Azure Login action all the time, and you need to setup one or more dedicated Service Principals in advance so you can actually interact with your tenant.

    - name: Subscription Login
      uses: azure/login@v1
      with:
        creds: ${{ secrets.<your secret name> }}

Once you have a Service Principal you need to store it - I recommend to create an environment secret, as this is scoped to the target environment like the name suggests. These are encrypted within the GitHub platform, but they cannot be linked to something like Azure Key Vault. You can also use an organisational secret, if you want to share them across multiple repos or environments, but I would rather use permission scoping wherever possible!

No templates or stages in GitHub Actions

There are no templates in GitHub Actions, plain and simple - this leads to little reuse if you don’t plan it well in advance. Looking at the public roadmap, they are targeting Q2 2021 for centrally managed templates and an undefined future for private templates as in Azure Pipelines.

There is also no real concept of stage in GitHub Actions. Your stages will be separate YAML files, and you can invoke them as needed. It’s just different.

You require a deeper knowledge of what you are targeting

If you use Azure Pipelines, every time you add a task you can inspect anything related to it via the Task Assistant in your editor, so even if you don’t know all about it you can get an idea about what you can do with it:

The closest you can get to that is looking at the GitHub Marketplace listing and at the examples contained in there:

It’s a different approach - more control at the cost of being less intuitive.

Running a workflow manually is not as simple as it should be

GitHub Actions is a platform orchestrator that happens to do CI/CD. There is no such thing as a manual run, so you need to add this snippet to your on condition:

on:
...
  workflow_dispatch:
    inputs:
      logLevel:
        description: 'Log level'     
        required: true
        default: 'warning'

This will enable the relative UI:

It’s not out-of-the-box and you need to know what to change - I hope it will become simpler in the future. Sometimes you need to run a workflow manually, and you don’t want to pollute your commit history with whitespace changes…

Why DevOps won't save you from struggling during the COVID-19 pandemic

Sat, 16 Jan 2021 00:00:00 +0000

New year, first new post. This is a reflection I’ve been mumbling over for the past few months.

I am building up a session about DevOps during the COVID-19 pandemic, and when researching things I quickly found a trend I frankly disagree with: apparently, DevOps on its own should warrant a boom for technology and quality within teams working within the technology industry.

Look around yourself:

Solving the DevOps Dilemma in the COVID Era

How DevOps Can Save Your Business from COVID-19

Why DevOps Is Important During the COVID-19 Pandemic

Work-from-home mandates may be DevOps’ shining moment

I can go on and on. DevOps as the silver bullet. Don’t get me wrong, it might be right for some. DevOps is the best way forward, but results coming out of a good adoption plan are not a direct consequence of doing DevOps. It’s not like you are suddenly going to turn things upside down and adding all the best practices, the automations and the tools you could think of overnight just because you are working from home.

Let’s bring it closer to home: teams are made of people, and we all work remotely now, from our homes. I lead a team on a daily basis, and I am lucky enough to have a dedicated room to work from with all the equipment necessary (even too much of it sometimes…). The struggle is real - no Teams, Slack, Webex can replace our human interactions. All the side-of-desk conversations are now gone, all the random conversations happening in shared spaces stopped, nobody bumps into each other anymore.

This has got a direct impact on the way people behave and the way they work in a DevOps environment.
There is an overhead (and in human terms, overhead means stress increase) in any activity that requires human interaction - be it open a chat on Teams, starting an impromtu meeting, anything now requires a conscious effort which is inhevitably higher than the in-person equivalent.
People are naturally blurring boundaries, which is unfortunate to say the least. People are learning new things all the time, and you can see the fight between sticking to the new versus old and trusted habits. It’s not easy, and our 24x7 hyperconnected world adds a new variable to it.

It is taxing, and you can see it day in day out. I take steps every day to make sure people are not just engaged on the technical side but also as part of the broader fabric of the team and the organisation. We are not just connected from our homes to work, we still need to remember the human side of things. Cultural differences, mistakes, communication misunderstandings will happen no matter what, and they will also be amplified by the partially disconnected nature of the shift towards remote work.

From a technical perspective you can see that people are more reactive, and it means that the overall quality can either increase or decrease.

It’s not a one-way system: people can actually suffer from being disconnected from being with one team in a room and actually decrease the quality of what they do. These people will lack the passive input of colleagues, the ideas brought out of a conversation with a colleague over a cup of coffee. Pull requests will take longer, you could see someone suddenly communicating less and be more isolated on a technical problem. Bugs might pile-up, or become more specific. Someone might just be dropping the ball from time to time. It’s not stuff you sort out by installing or deploying yet another tool, or by adding a stand-up meeting.

Like i said - teams are made of people, you will never get a constant output or a predictable reaction. Listen, adapt and try to steer accordingly.

How I moved my demo SonarQube server to Azure Container Instance

Fri, 27 Nov 2020 00:00:00 +0000

Yesterday I realised that the last time I connected via RDP into a server was back in May.
That talks volumes about how much cloud-native I am doing these days, but it also made me feel the burden of dealing with a Virtual Machine: logging in, dealing with the whole OS, an overall sense of slowness.

The reason why I logged in that VM is because I wanted to update one of my demo instances of SonarQube, which I use in all sorts of demos due to the amount of data I have in there.

It’s been a while since I updated that specific one, so it was about time. That is where my issues started - I tried to update to the latest LTS, no luck because of the version of Java I installed on the VM. The latest version of Java is not supported either, and retrieving specific versions of the JRE/JDK is not exactly straightforward. Then ElasticSearch complained, then something else.

After a while I managed to get to the LTS, but then I had other errors when trying to move to the latest version. It’s not SonarQube’s fault in fairness, as much as mine as I neglected this specific demo instance. It was time to move away from a Virtual Machine and into something nimbler.

SonarSource now offers SonarQube via a Docker image - an amazing start. Running it with the H2 database is a breeze - either in a Web App or a container.

I immediately excluded AKS due to my scenario not requiring the complexity of Kubernetes, so I started looking at Azure Container Instance. This is what you need if you only need to run a container in a lift-and-shift scenario, no need for any extra complexity.

SonarQube in ACI works a charm, but I wanted to use my own database - and that’s where the problems begin. How do you pass the required information to SonarQube if you are running in ACI? And also - how do you keep control over the instance?

So, rolling up my sleeves - you can provision an ACI with Environment Variables which allow a user to inject variables into the target container at startup. SonarQube now supports them - so you need to setup your ACI with them:

If you provision this from scratch please use an ARM template like I did, it will allow you to set the SONARQUBE_JDBC_PASSWORD variable as a secret string!

So you can run SonarQube with a real database. But it won’t start - you will get an error from ElasticSearch. Long story short, you need real, persistent storage for ElasticSearch as you are now running a non-empty instance of SonarQube.

The easiest solution here is to create a Storage Account and to setup file shares to be passed to our ACI as mount points. I did that for the four folders I was really interested in:

I wanted to keep control of the conf folder, the data folder, the extensions folder and the logs folder. Each one of them is mounted on the /opt/sonarqube/<folder> path - hence /opt/sonarqube/conf, /opt/sonarqube/data, etc.

For the conf folder, the reason why I wanted to keep it under my control was to upload a sonar.properties file containing properties I am interested in overriding by default (like the port to use, or the dreaded sonar.search.javaAdditionalOpts=-Dnode.store.allow_mmapfs=false)

The data folder is necessary for ElasticSearch, the extensions folder is where you will find all the various installed plugins, and the logs folder contains all the SonarQube logs. This allows me to maintain a degree of control over the container in use, while still allowing the image to be refreshed anytime without worrying about breaking changes.

You can find my ARM template and deployment script here - it is very simple, but it works for demo purposes. If you want to make it better, you should tighten the database firewall rules and add a nginx reverse proxy via the sidecar pattern so you can get HTTPS implemented too.

Beware of implicit triggers in Azure Pipelines!

Wed, 25 Nov 2020 00:00:00 +0000

I was talking with Mohamed about this earlier today - it’s something that can make you think you are off the track while in reality there is a much simpler explanation :-)

Let’s say you have this pipeline - the traditional:

pool:
  vmImage: 'ubuntu-latest'

steps:
- script: echo Hello, world!
  displayName: 'Run a one-line script'

This is a CI build - you have no trigger, but as per documentation you have an implicit trigger on all branches (as per documentation).

The main thing to be aware of is that this type of trigger will operate on all branches, and on all events. All events include branch creation as well, so don’t be surprised if you see a slew of pipelines running when you create a branch - chances are you are using an implicit trigger and they are running as expected!

No message found for this issue in Azure DevOps

Wed, 11 Nov 2020 00:00:00 +0000

I am writing this post because I’ve been asked four times within two weeks, so it acts as a public service announcement :-)

The stage is still successful. Looking deeper into the execution by setting System.Debug to true, you can see in the logs that it might have got to do with the Service Principal in the ARM deployment task:

In reality, it doesn’t - there was definitely some change to the out-of-the-box task, as this is not the expected behaviour.

This GitHub issue explains what the problem is, and hopefully it will be sorted soon!

An API layer of PowerShell-based Function Apps - a few tips

Wed, 14 Oct 2020 00:00:00 +0000

Something that’s really fascinating for me is how serverless brings new life to existing pieces of technology - in this case, Azure Function Apps. PowerShell-based ones in particular.

I am sure you are familiar with Function Apps and serverless computing, and the fact that amongst the various runtimes at your disposal you can even use PowerShell to write the logic inside them. When it comes to interacting with Azure and parsing files PowerShell is really second to none, and it makes our lives really easy. Embedding scripts (especially if they interact with an Azure estate) onto an Azure Function transforms them into a lightweight yet powerful API layer.

Once you start doing that, you will need a CI/CD process, and that’s where things become interesting…

Getting started - CI/CD

First of all I would recommend a repository per App Service Plan.
Azure Functions are simple, nimble pieces of code, and they are designed for being hosted on a single App Service Plan - so it makes sense to actually group them like this.

Once you have them there, add the ARM template or your favourite Infrastructure as Code equivalent. You need that so it’s all reproducible!

Eventually, your CI/CD pipeline should have multiple stages - one for the infrastructure to be deploted or refreshed, and another one to deploy your Function(s).

The deployment itself is the simplest thing ever: PowerShell doesn’t need to be compiled, so you can just zip the code in a package file and push it via the relevant Pipelines task to Azure. All you need to do is to target your Function App, every Function will be loaded independently.

...
stages:
- stage: Infrastructure Deployment
  jobs:
  - deployment: TargetEnvironment
    environment:
      name: "My target environment"
    strategy:
        runOnce:
          deploy:
              steps:
                ...
- stage: Functions Package and Deployment
  jobs:
  - job: Package and Deployment
    steps:
    - task: ArchiveFiles@2
    inputs:
        rootFolderOrFile: '$(System.DefaultWorkingDirectory)'
        includeRootFolder: false
        archiveType: 'zip'
        archiveFile: '$(Build.ArtifactStagingDirectory)/$(Build.BuildId).zip'
        replaceExistingArchive: true

    - task: PublishPipelineArtifact@1
    inputs:
        targetPath: '$(Build.ArtifactStagingDirectory)'
        artifact: 'Middleware'
        publishLocation: 'pipeline'
  
    - task: AzureFunctionApp@1
    inputs:
        azureSubscription: 'YourCSN'
        appType: 'functionApp'
        appName: 'YourFunctionApp'
        package: '$(Build.ArtifactStagingDirectory)/$(Build.BuildId).zip'
        deploymentMethod: 'auto'

Should I group them?

The one above is just an example, but it gives you an idea. If you package everything in a single zip file, it will work fine. If you want granularity, you can have individual pipelines for individual functions, and as long as you target the Function App you are good to go.

Pair them with a Managed Identity for a managed and powerful API layer

You can easily add a Managed Identity to a Function App, and once the AAD Application Registration is secured you can leverage that to provide your users with self-service APIs spanning across your Azure estate.

Remember that you have the full power of the Az commands in PowerShell, so everything you did up to today to automate tasks can be easily ported across. Putting that into an API gives it a whole different exposure.

Connect Azure Active Directory to secure the API layer

Integrating Azure Active Directory with your Function App is fairly simple, and it gives you control over who can access the API. Integration is straightforward, and it allows you to control access via RBAC.

It’s all very powerful yet easy to setup and integrate, an extremely useful way of extending your automations and ensuring as many users as possible can benefit from them within your organisation.

DevOps in a Landing Zone, how to run commands across it with Azure Resource Graph

Sat, 05 Sep 2020 00:00:00 +0000

I am currently working with a client that’s got a very well made Landing Zone (we are talking tens of subscriptions with nested Management Groups), and my team is building Azure Pipelines running automations that need to span across the whole Landing Zone.

If you ever find yourself in this situation, remember that Azure DevOps is very well equipped for this - you can register Service Connections that span across Management Groups, including the root one:

That said, even if you build something that can potentially be generalised to the whole Landing Zone, you will quickly realise that you have a problem: scoping.

Scoping for an Azure command means that whenever you run anything against it you will always be scoped to a subscription. Set-AzContext is a very clear example of this, and obviously while you can work around it by looping any command across all the contexts your account or Service Principal has got access to, in a Landing Zone this quickly becomes an unnecessary overhead.

So how to solve this problem? The answer is Azure Resource Graph.

An Azure Resource Graph query can span across the whole Landing Zone. Let’s say you want to deploy an update to every App Service running in a certain location. If you have tens of subscriptions where you need to perform this, it can be a big task. With Resource Graph, you can retrieve the information required like this:

and then run the query with az graph query -q "<your inline query>". The list of Resource IDs can then be used as an input for the many Azure commands you might want to use, and taking away the requirement of scoping to a subscription or a Resource Group.

Importing pipelines when the root pipeline has not been imported

Tue, 01 Sep 2020 00:00:00 +0000

I ran into this interesting bug the other day - let’s say this is our repository:

All I wanted to do was importing the console.yml pipeline in Azure Pipelines. Well, I quickly learned that if you do not ever import the azure-pipelines.yml file first you are not going to be allowed to do that:

There is a way around this though - if you use the Classic Editor you will be able to point the import process at an existing YAML pipeline.

Nifty little bug, hopefully it will be fixed soon.

Bulk import YAML pipelines in Azure DevOps

Tue, 21 Jul 2020 00:00:00 +0000

If you import or fork a repository with many YAML pipelines you will soon face this issue…

How can I import all these pipelines?

Doing it manually would be quite tedious, so you should use the APIs. Or, even better, the Azure DevOps CLI!

Assuming you are going to get a list of paths in a standard format, you can run this simple PowerShell script from a local copy of your Git repository…

$pipelines = <your paths/pipelines/names/etc - something to uniquely identify your pipelines>

foreach ($p in $pipelines){
    az pipelines create --name $p --description "Pipeline for $p" --repository <your clone URL> --branch <branch> --folder-path <folder destination for pipelines> --yaml-path <the path where $p is> --skip-run
}

As simple as this is, it is quite a valuable script.
Given a source of standard paths or pipeline names (you need to build it as you like), it is going to create new pipelines importing the existing YAML files, sorting them into the destination folders you like in Azure Pipelines and skipping the initial run so you are not going to overwhelm your agent pool.

Did you know about the Azure DevOps App?

Thu, 02 Jul 2020 00:00:00 +0000

The title is a bit cheeky… but I just realised that you can pick-up a website in Edge and make it an app by clicking on this item here:

Now, what if you do that with an Azure DevOps organisation? You get a nice bootstrap-native app to be pinned anywhere you like:

I keep my main organisation pinned on the Start menu for ease of access.

It is nothing more than a webpage without the whole browser plumbing around, but from a usability point of view this (at least to me!) makes a world of difference!

What's new in Microsoft Security Code Analysis?

Mon, 29 Jun 2020 00:00:00 +0000

I blogged about the toolkit in the past, Microsoft Security Code Analysis is something that you should look at if you want to integrate a solid set of static code analysis procedures around the security space.

Over the past couple of months the team released a major set of enhancements, and it is clear that there is still so much coming through to properly implement security scans in Azure DevOps.

CredScan updates

Aside from being 25% faster, CredScan can now identify new secret types, including various types of access tokens. This was a long-requested feature, because not all passwords are a username and password combination and having the capability of automatically detecting these is extremely important. You definitely do not want an Azure Active Directory access token in the clear into your repository!

Futures

There a few interesting items in the roadmap: analysers for Java, Python and Azure Resource Manager templates. These not only expand the language selection, but they will also cover Infrastructure as Code files, making it a foundational tool you can integrate not only for .NET code, but also for other languages.

Getting started with project management in GitHub Projects

Sun, 21 Jun 2020 00:00:00 +0000

If you want to approach GitHub Issues for your projects, sooner or later you are going to need a form of project management. It can be Azure DevOps (and I am very keen on it), but what if you want to retain everything within GitHub? The answer is GitHub Projects.

GitHub Projects is definitely designed around a board and a Lean process - all of the default Template options point at that direction:

Automated Kanban will get you started with a good amount of helpers to get it off the ground. You can also link repositories to a board, which is the best way of populating a board:

For our example, let’s pretend I am creating a board that unifies the GitHub Issues the teams are working on and provides a unified pane of glass for all the current activities. If you are starting from scratch, then you are done - you get a board, and you can start adding stuff to it:

What you see there as cards are not necessarily Issues coming from repos - you can also have independent cards, and everything is markdown-based anyway so they are easy to edit.

In the real world it is quite unlikely to start in a nice, greenfield situation. More often than not you will need to setup a Board for an existing repository, which might already have a number of issues making up a backlog.

In that case, the first thing to do would be to add the issues you want to this board. I linked two repositories with existing data, hence I need to add these:

You can do it manually once or twice, but after a while it becomes an overhead…

Needless to say, we have automations. If you set the Projects property for an issue, it will be automatically be linked to the Project:

Also, any issue set to a Closed state will automatically go to to the Closed column.

All nice and good, but it’s not enough to have a simple setup out of the box. A key missing bit, for example, is that you might want to move an issue when it’s assigned to someone into the In progress column, and the out of the box automation doesn’t do that.

That is where GitHub Actions enters the picture - thanks to one of the many actions in the marketplace you can create a workflow like this, and every time an issue gets someone assigned it will be automatically moved to that column:

By implementing this workflow to any linked repository you will get a nice and smooth management experience for a Lean backlog. There is obviously much more to it, but it is a starting point to real project management in GitHub.

Running YAML Azure Pipelines from a restricted GitHub Service Connection

Thu, 04 Jun 2020 00:00:00 +0000

Last week a colleague (hi Kapil!) ran into an interesting scenario:

what if I can’t use the GitHub app to integrate Azure Pipelines with my GitHub repository? All I have is a GitHub PAT.

The target GitHub repository contains the YAML Pipeline definitions, but it has no visibility towards Azure DevOps. All you have on the Azure DevOps side is a Service Connection created with a PAT.
This is a situation where the GitHub organisation restricts access to external parties, so they only release a PAT to allow for controlled access. It’s not an optimal situation IMHO, but we should make it work regardless.

If you choose the Azure Pipeline classic editor, you will be able to consume that Service Connection:

You will be surprised to discover that once you point it at the right source (your GitHub Service Connection mentioned above), you will have an option to use a YAML file:

All you then have to do is to set the path to your YAML definition, and the two will be integrated:

Working with Git repositories in Azure Pipelines

Sun, 24 May 2020 00:00:00 +0000

I keep talking about Azure Pipelines a lot these days and there are so many features in the Pipelines as Code implementation you just miss or overlook because you cannot go around the UI, poking stuff, turning dials and seeing what happens. At least, that’s what I always do :-)

This time around I want to spend some time on what you can do with Git repositories in Azure Pipelines, because once you start embracing Pipelines as Code there is so much you can do with them - regardless of your versioning approach (single or multiple repositories).

Working with multiple Git repositories

One of these features is multi-repository access, and it gives you so much power over the handling of repositories as part of a pipeline run.

Reaching out to multiple repositories, within a Pipeline is very simple, by leveraging the appropriate Resources keyword and checking-out the repository you are interested in - it can be hosted anywhere, as long as it is reachable via a Service Connection:

resources:
  repositories:
  - repository: ExternalRepository
    type: github
    endpoint: GHEC
    name: Org/Repo
...
steps:
- checkout: ExternalRepository
...

What if you want to specify a repository at runtime, rather than as part of the definition? If that repository is contained in your Azure DevOps Organisation (anywhere!) you can just run this as part of your steps, replacing the stuff within brackets:

steps:
...
- checkout: git://<Team Project>/<repository name>
...

You can also choose the branch you want to checkout, by adding a ref property to the repository resource or appending _@ to the checkout step:

resources:
  repositories:
  - repository: ExternalRepository
    type: github
    endpoint: GHEC
    name: Org/Repo
    ref: develop
...

steps:
...
- checkout: git://<Team Project>/<repository name>@develop
...

One typical example of multiple repository access is when you have a repository containing your Pipeline templates, and you need to run some of them as part of your specialised pipeline run, contained in a different repository (a microservice, for example). It’s as simple as this…

...
steps:
  - template: templates/my-template.yml@ExternalRepository
...

Trigger filtering for branches and Pull Requests

Yes, when you create a pipeline you get a CI trigger on master by default. But it is just the beginning…

trigger:
  branches:
    include:
    - master
    - develop
    - feature/*
    exclude:
    - experimental/*
  paths:
    include:
    - '/'
    exclude:
    - 'docs/'
    - 'assets/'

This example runs a certain pipeline on a CI basis only when a change is pushed to master, develop or any feature branch. It explicitly excludes experimental branches, and changes to the docs/ and assets/ folders. No fiddling around with comboboxes or toggles, you just type it down like this.

If you are using Azure Repos, then the Pull Request trigger is going to be handled by a Branch Policy and you should not do anything to your Pipeline definition. If you are using any other Git hosting platform, then you can copy the code above and replace the trigger keyword with pr to implement a trigger filter for PRs as well.

Azure DevOps as the FinOps enabler

Sat, 16 May 2020 00:00:00 +0000

I recently spent a lot of time working on this topic, which in a nutshell can be summarised as:

Can I make Azure DevOps my FinOps enabler instead of re-inventing the wheel?

Let’s take a step back. FinOps? Yes, FinOps.

FinOps is a reality of the world we live in

If you are using the Public Cloud, you are effectively using a utility. Hence, you are billed by a meter reading, and the more you use the more you pay.

FinOps is an engineering specialisation that bridges the gap between the world of financial management (there is still a procurement function in every organisation, and guess where the purchase order for an Azure subscription is screened and approved or rejected?) and the technology side.

The name is carefully identified as FinOps because of that - it actually stands for Cloud Financial Operations, but it is not trying to rip-off the success of DevOps.

It is a deliberate choice based on the fact that one of the DevOps pillars is about removing silos and communication barriers. FinOps does applies the same treatment to Procurement (the people actually paying for the cloud resources) and Engineering Operations (the people using these cloud resources).

Why Azure DevOps?

Think about it for a moment. With Azure DevOps (and Azure Pipelines in particular) you can have total control over the automations that provision and deploy the cloud resources you are going to use.

Pipelines can be scheduled, and Service Connections allow you to connect to anything in Azure, from a Management Group down to an individual Resource Group, and you can always execute either PowerShell scripts or ARM templates against Azure to achieve the desired state.

It doesn’t take too long to understand that these are all the tools you need to empower your development teams towards a smart cloud usage.

It works regardless

Remember: you are on a meter, you pay for what you use. Do you really need that development environment running 24x7? Perhaps not, and you might make your application more resilient to restarts in the process of implementing that.

Each team can and should integrate this core FinOps principle in their habits and procedures so that it becomes part of the fabric of your organisation.

You might have circumstances where a team doesn’t want to collaborate, or maybe there are other constraints limiting their involvement. This is not a problem with Azure DevOps, as long as you have a Service Principal that can connect to the target Azure resources.

If you need to go down the centralised management route, take advantage of YAML pipelines. Create a dedicated Git repository containing all the infrastructure pipelines you need, so you get a clear auditing trail.

Also leverage Environments as much as you can in the process - they cost you nothing to implement them and you also get a clear separation for visibility purposes.

CI/CD YAML Pipelines finally GA!

Wed, 29 Apr 2020 00:00:00 +0000

YAML pipelines for CI/CD are finally GA. Hooray!

There are a few changes which have been introduced fairly recently: resources, as well as a number of approvals and checks.

Resources

Resources are the built-in mechanism for consuming resources as part of a pipeline.

resources:
  pipelines: [ pipeline ]  
  builds: [ build ]
  repositories: [ repository ]
  containers: [ container ]
  packages: [ package ]

This is the syntax to use when it comes to multi-repository builds, composition as part of releases, etc.

In real-world situations you can have a situation where you have to deal with these (and more), so you are not tied to a single repository. Also, they enable a very interesting scenario: a reusable repository containing pipeline templates, which you can re-use across your organisation. A very cool example of inner source.

Approvals and checks

This has been a long-standing request before GA: you need to have approvals, you need to control how releases progress from environment to environment.

Now, it’s not just about approvals here. You can also invoke an Azure Function, a REST API or query Azure Monitor like we did in the old Release Gates. My AvailabilityFunction was designed for that!

At the same time, the bottom check is extremely interesting - requesting a Required template you can make sure certain stages adhere to a certain convention across the organisation. It’s pretty much the equivalent to a blueprint:

Evaluate artifact is another one worth a mention. Artifact policy checks have been around for a while, and they currently apply to container pipelines. They act as a gatekeeper with a set of policies that cover many things, from what ports are exposed to which images are consumed - providing again not only a level of standardisation but also an automated validation which can prevent security or quality issues.

I am a massive fan of Pipelines as Code, especially in the Azure DevOps implementation. You have all the power of YAML and Pipelines as Code (including versioning and reproducibility, which are the two most important ones IMHO!) together with an easy UX when building them thanks to the Task Assistant.

Now they are GA for the release side as well, so there is no excuse for not using them :-)

Synchronising GitHub Issues and Azure DevOps Work Items

Wed, 22 Apr 2020 00:00:00 +0000

Another integration between Azure DevOps and GitHub is in work planning and tracking, or project management if you like.

While from a technical perspective they will be achieved in a similar way, I believe we have a number of possible scenarios, with a couple of examples below:

use Azure Boards for backlog management, as well as having an open source or inner source model where stuff is published to GitHub and issues from consumers are publicly logged from there.

be independent from the project and portfolio management side of the story, where the PMO rolls backlog data coming from GitHub Issues into Epics and Features hosted natively in Azure Boards.

The solution is very straightforward - use Dan Hellem’s Action as it is, and mapping the Azure DevOps Work Item Type of choice to what makes the most sense in your circumstances. You could even use a different Area Path, if you want:

Let’s say we are tackling the first scenario: in that case opening an issue in the GitHub world will create a Bug in Azure DevOps, so that external contributors will have an opportunity of opening something in your backlog, with various reminders of the connection to GitHub:

This also means that if someone, as part of a Pull Request, mentions that specific issue via the AB# syntax in a comment, commits will be automatically associated to the Azure DevOps Bug!

This enables a real contribution workflow at both ends, where the GitHub Issues are treated as first class citizens rather than an afterthought.

The integration is deep both ways, as it requires the Azure Boards GitHub application on the GitHub account or organisation, and it will automatically configure the GitHub Connection on the Azure DevOps side:

On top of that, take a look at the Action’s source code - extending that will open the Pandora’s box when it comes to customising the Work Item created by the integration:

It is effectively a wrapper around the REST API, so you can tailor it down to your needs!

Review - Team Topologies

Tue, 14 Apr 2020 00:00:00 +0000

I bought this book a few weeks ago after a suggestion by fellow MVP Wouter de Kort:

Just purchased!
— Matteo Emili (@MattVSTS) February 9, 2020

It was definitely worth it. Team Topologies covers a lot of ground, it’s not your standard management book despite its 180-odd pages length taking out glossary, index and references.

The thing I liked probably the most is that the book uses Conway’s Law as it is supposed to be used. It’s an unfortunate reality we deal with on a daily basis, but it’s not like the world is divided between who uses this law and who doesn’t…there are a number of shades in between, and Chapter 2 closes with this paragraph:

Conway’s Law Is Critical for Efficient Team Design in Tech

It’s well known I am a big fan of pragmatic approaches that bring tangible benefits: the reverse Conway maneuver is an excellent start, which then you will adapt to the real case in front of you. Sometimes, you just have to deal with it. And the best way of dealing with it is bending it to your advantage.

Then it moves on to Team Topologies (the actual topologies, not the title again!). The book delves into psychology, and it really resonates - so many times situations like the ones described actually happened. I experienced them first-hand, and there are plenty of things to takeaway as retrospective. Applying the outcomes from the book already made the difference in a couple of cases.

But that said, the book is very clear:

Team Topologies Alone Are Not Sufficient for IT Effectiveness

Nobody is going to find the silver bullet in this book, but it gives a lot of good for thought. It’s proper good. If you are in a consulting capacity, even a junior one, technology is just a tool: you are dealing with people, first and foremost. Technology always comes second in the pecking order.

What does "automate your workflow" means?

Tue, 07 Apr 2020 00:00:00 +0000

GitHub’s marketing headline is very clear IMHO:

But marketing aside, what does it actually mean?

GitHub Actions is not just a CI/CD engine, its integration with the platform goes much deeper. The more I spend time with it, the more I find out these perhaps simple but (to me!) valuable bits.

It’s true that we often bend Azure Pipelines to do things which are not really within the defined scope of work, but that’s a side-effect of Azure Pipelines being extremely flexible. Pipelines is a CI/CD engine that can be a general purpose orchestrator, Actions is the other way around.

Let’s say, you might be here because of a tweet like this:

That tweet was not manual. That tweet is the output of my custom workflow (thanks to Ed for his Action!):

This workflow runs on every push to master, unless the commit message includes NO CI. If the workflow is running it will pick up the comment from the commit (which by convention it is always going to be the title of the post) and tweets it in a pre-built body.

“Automate your workflow” means this. Not just CI/CD, but an underlying orchestrator spanning across the platform, where the main artifact is code.

CI on GitHub Actions, CD on Azure Pipelines

Fri, 03 Apr 2020 00:00:00 +0000

If you want to start approaching GitHub Actions, you can easily do that targeting Continuous Integration.

However, when it comes to the deployment side of the story, it can be more difficult. Requirements can be different for everyone, and Pipelines as of today has an established set of patterns and features people already use.

Also, when it comes to GitHub Packages, there is one key missing item compared to Azure Artifacts: Universal Packages. They are a very effective way of moving stuff around, and as of today GitHub Packages does not support them.

So you want to use GitHub and GitHub Actions for all things development. It’s not a problem, you will setup a workflow and build your stuff. But for deployments you want to use Azure Pipelines because you are already very familiar with it, you use Service Endpoints extensively, or whatever other reason.

Nobody is stopping us from integrating Actions and Pipelines, with Azure Artifacts in between. It is relatively simple, and it provides good flexibility.

Let’s take a step back: what do you do with any project in your organisation? You run a CI engine that produces an artifact. That artifact can be deployed on multiple target environments, often also outside of your own project if you are working on a platform team or you are doing inner source.

Taking for granted you are already building your artifacts as part of the build process, all you need to add a couple of Actions to your workflow:

    - name: Publish package
      uses: Azure/cli@v1.0.0
      env: 
        AZURE_DEVOPS_EXT_PAT: $
      with:
        azcliversion: 2.0.72
        inlineScript: |
          az extension add --name azure-devops
          echo $ | az devops login --organization https://dev.azure.com/<orgname>
          az artifacts universal publish --organization https://dev.azure.com/<orgname>/ --project="Your Project" --scope project --feed <your feed name> --name <artifact name> --version 0.0.$ --description "Description" --path <path of your artifact>
      
    - name: Azure Pipelines Action
      uses: Azure/pipelines@v1
      with:
        # FQDN to the Azure DevOps organization with project name
        azure-devops-project-url: 'https://dev.azure.com/<orgname>/Your%20Project'
        # Name of the Azure Pipeline to be triggered
        azure-pipeline-name: '<your pipeline name>'
        # PAT
        azure-devops-token: $

Again, in Actions you have no Service Endpoint infrastructure so you have to deal with the cli directly. The first action uses the Azure CLI with a PAT added to the Secrets section of your project - you then add the azure-devops extension, authenticate and then publish a Universal Package to Azure Artifacts.

Authentication is quite tricky here - despite all my efforts, I still had to echo the PAT before logging in. The Azure DevOps CLI does not support either Service Principals or PAT as a parameter, so I had to go that way. It does not leak in the Actions log, but the environment variable alone was not enough to successfully authenticate.

The reason why I chose a Universal Package is because it allows for easy and transparent flow of packages regardless of the content. If you are using MSDeploy for example, it is the way to go. Don’t pay too much attention to the use of the GitHub Actions Run Number, I just needed a quick incremental number to use for versioning.

This process will publish the artifact(s) on the feed specified. Using a feed enables easy sharing of artifacts not only between GitHub and Azure DevOps, but also within projects contained inside the Azure DevOps organisation if the feed is configured as org-wide.

The second Action invokes an Azure Pipeline, and it doesn’t require too much effort: FQDN, pipeline name and PAT will be enough to get you going. Of course that Pipeline should consume the feed we just published to!

This is all it takes to integrate the two platforms - it is fairly straightforward once you iron out the differences. A question I got while discussing this is:

Why don’t you use GitHub Releases or GitHub Packages as artifacts repository?

Obviously I chose Azure Artifacts because I wanted to integrate Azure DevOps and GitHub within my context :-) but there are other reasons: I did not use GitHub Releases because I wanted the artifacts to be independent of the repository at GitHub level, effectively making the code and CI side of the story pluggable. I also didn’t want to tie down the deployment pipelines with an artifact source.

The reason why I didn’t use GitHub Packages is simple: there is no support for a generic (Universal) package which can contain a MSDeploy package. MSDeploy is used fairly heavily, especially when deploying on Azure - I might be changing the underlying DevOps platform, but I am not going to revamp a situation where things are already established and well-oiled.

A tour of GitHub Enterprise Cloud

Sat, 28 Mar 2020 00:00:00 +0000

Continuing my exploration of GitHub from Azure DevOps, the next topic which caught my attention is the equivalence between Azure DevOps and GitHub at service level. I am particularly interested in GitHub Enterprise Cloud, which seems to be the closest match to what I am already familiar with!

Organisations

In Azure DevOps Services the first thing you do is creating an Organisation (it used to be Account and it is a Collection in the on-premise world). When you go to GitHub.com, what you create straight away is an individual account. How would that work with enterprise ownership?

The answer is the same, albeit slightly hidden: GitHub Organisations. It’s not in-your-face that much - you can find the Organisations page under your Settings:

An organisation can totally be free - there is no cost attached to it if you use it for open-source development. If you need private repositories (and development) then you can create a Team plan or an Enterprise plan, with the relative cost.

Once you move towards Enteprise Cloud, getting into the Organisation side you will be faced with a set of familiar set of settings and menus, but there are a few differences comparing them with Azure DevOps’.

Permissions and Security

All the ACL are handled under the Member privileges menu, as well as various visibility settings.

For a user, there are four base permissions:

Unless a user is added to a specific Team or Repository, it will automatically inherit this base permission.

From the same page you can also expand the Forking capability to private repos, and control the Actions integration. This is interesting - you have three settings: Disabled (I wonder who will ever disable Actions!), local Actions and local and third party Actions. It is a nice way of enabling vetting for Actions should you need it - with the local Actions setting you are retricting usage to Actions where the code is contained within an Organisation’s repository.

On the Security front you can require 2FA for all users contained in an Organisation (please do!), integrate SSO with your identity provider of choice, synchronise teams via AAD, add a SSH CA and implement IP whitelisting.

The last one is very interesting for the Enterprise world, and it is nice to see such transparency about it. It is worth knowing that once you enable IP whitelisting you lose the ability to consume the hosted GitHub Actions runners, and you need to host your own.

Managing a project

Unlike Azure DevOps, you do not require a Team Project in GitHub. The approach is different - everything revolves around code, so you can have loose repos where all the members of an Organisation can contribute.

A Project in GitHub is a set of features to enable a basic planning and tracking experience. One or more repos can be linked to a Project to facilitate suggestions and search. A Project can have a Project Template, but do not expect anything like in Azure DevOps - here things are very lightweight and prone to automation:

The Basic Kanban template is really the simplest one you can start from - all the automations from the other templates are implemented via GitHub Actions.

You can immediately see that there is no choice between Agile, Scrum or CMMI in terms of templates, it is an experience completely decoupled from your process. Needless to say you can customise anything and everything.

Teams

A Team is a way of grouping people and granting access to common resources together. You can assign Projects, other Teams and Repositories to a Team, so that all the tracking effort can be targeted by these groups.

The main aim of a Team is to facilitate discussions - they can be used to track decisions and conversations before formalising them in Project issues.

Anything else?

That is it for Enterprise Cloud, the differences with Azure DevOps are pretty much summarised in the above list.

What I really like is the lack of overhead. From an administrative perspective there is no need for a full-time role managing the organisation and things are really transparent. Teams can focus on creating value without spending too much time in administrative tasks, and there is a large focus on communication and information sharing within the platform.

We should also keep in mind that this approach doesn’t require to go all-in with a massive change to the way teams work today. I am fairly sure only a relatively small percentage of teams will take advantage of all the features an Organisation can offer from the get-go, often because of longstanding habits and resistance to change.

There is nothing wrong with it, and GitHub Enterprise Cloud is granular enough to offer a seamless experience regardless.

Looking at the CD side of CI/CD with GitHub Actions - also how to deploy ARM templates with it!

Mon, 10 Feb 2020 00:00:00 +0000

It’s been a while I wanted to spend proper time with GitHub Actions and compare it with Azure Pipelines. Today thanks to the storm this weekend I had some time to do so :-) It’s a long and wordy post, be advised. And no, no TL;DR!

GitHub Actions is built on the same foundation of Azure Pipelines, so the Continuous Integration side is very much what I am expecting from it: a series of tasks (Actions) running on an agent (Runner). The definition is contained in a yaml file (by default within a .github/workflows folder) and is stored in your Git repository.

Nothing out of the ordinary up to this point: you will be dealing with a slightly different syntax, but it pretty much to what Azure Pipeline does.

Now onto the Deployment side of the story, that’s where things get interesting. GitHub Actions as of today has got no deep integration with any cloud provider, or any authorisation automation for external resources.

The premise is completely different from Azure Pipelines - you can (and should) use standard tools so that your local workflow can be automated. Hence, all the work we usually do around Azure CLI, PowerShell, Bash, etc. can be ported to Actions with minimal changes.

There are several actions already available on the marketplace, so stuff like deployments or integrating existing automations won’t be an issue. Take this as a quite edge example: if you are running vSphere in your datacentre (so nothing to do with any cloud) you can deploy a VM from the Content Library with just one Action as part of your deployment.

As a consequence of not having an equivalent to the Service Endpoint in Azure DevOps, you need to handle your secrets manually. This will entail, in the case of Azure, creating a Service Principal via the CLI and then building your own JSON structure with the four parameters you’ll need:

{
    "clientId": "<guid>",
    "clientSecret": "<another_guid>",
    "tenantId": "<different_guid>",
    "subscriptionId": "<separate_guid>"
}

Once you have this you can paste it into the Secrets section of your repository and then you will be able to consume it as a Secret:

Logging in with Azure will be the first thing to do on a deployment. After that (and assuming you have your ARM template available in the repositoru), given you do not have facilities for ARM deployments, you’ll need to use the CLI:

Now, as you could guess there is no ‘stage’ or ‘environment’ equivalence. The way you can manage target environments by mapping environment variables to secrets, and consuming them within your yml file.

There is also no daisy-chaining: an Action workflow cannot invoke another workflow without API workarounds or Webhooks. However you can call multiple jobs with job dependency:

Summarising, GitHub Actions is to Pipelines what the shift left movement is to a developer: it adds transparency, and it is very simple to deal with. YAML (despite the different syntax to Pipelines) is still YAML, so nothing completely new out there, as well as the Actions marketplace.

Cherry on top over here - you can invoke Azure Pipelines from a GitHub Actions workflow so you can move back and forth between both platforms should you need it, getting the best of both worlds!

A closer look at the pipeline authorisation model

Tue, 21 Jan 2020 00:00:00 +0000

It all starts from this error…

Yes, you can click the button and (possibly) fix it, but what was the cause of that?

The answer is simple: every Service Connection you are going to consume within a Pipeline needs to be authorised. What usually happens is that a Service Connection is automatically authorised for the project (or even across projects), and then someone decides to remove the pipeline authorisation leaving you with a red build.

Fixing this is really easy - your Service Connection has got a Security menu. Look into it…

Click on the + button to add at least a pipeline, or to grant full-fledged access across different projects:

Needless to say, you can restrict access as much as you like - play with the ACLs as much as you like, but regardless of that Pipelines and Users will have different authorisation models. Especially because Pipelines themselves are considered resources in the new YAML world…

A primer on using VMs with multi-stage pipelines

Thu, 16 Jan 2020 00:00:00 +0000

One of the most demanded features for multi-stage pipelines in Azure DevOps is the possibility of natively targeting VMs. As of today you can easily target Kubernetes environments and cloud-hosted environments, but it is not yet possible to consume a set of targets made of virtual machines. Unfortunately we do not live in an ideal world where all the workloads are running in PaaS or containers, so at the moment we really cannot use it at scale with VMs. This changes with the new feature released last Friday: you will be able to target VMs directly as well as the above resources. How?

It’s simple - the YAML syntax will have support for a new environment resourceType, called VirtualMachine. That one has got support for tagging and strategies designed around VMs. The best part IMHO is that it is completely transparent: once you have it setup you can keep writing your pipelines exactly like you would with a K8S or a PaaS environment.

All you have to do is to create a new Environment with a Virtual machine resource, specify the OS you are running and eventually run the associated script on your target VM.

There you will be able to enter the resource tags you might want to use (in my case, simply web). As simple as any other Azure DevOps agent deployment.

It’s all you have to do , once done you can start using your pipelines as usual. Let’s take a simple example - a modernised version of the PartsUnlimitedMRP sample app:

# Gradle
# Build your Java project and run tests with Gradle using a Gradle wrapper script.
# Add steps that analyze code, save build artifacts, deploy, and more:
# https://docs.microsoft.com/azure/devops/pipelines/languages/java

stages:
    - stage: Build
      jobs:
        - job: Build
          pool:
            vmImage: 'vs2017-win2016'
          steps:
          - task: Gradle@2
            displayName: 'Integration Service'
            inputs:
              workingDirectory: 'src/Backend/IntegrationService'
              gradleWrapperFile: 'src/Backend/IntegrationService/gradlew'
              gradleOptions: '-Xmx3072m'
              javaHomeOption: 'JDKVersion'
              jdkVersionOption: '1.8'
              jdkArchitectureOption: 'x64'
              publishJUnitResults: false
              testResultsFiles: '**/TEST-*.xml'
              tasks: 'build'

          - task: Gradle@2
            displayName: 'Order Service'
            inputs:
              workingDirectory: 'src/Backend/OrderService'
              gradleWrapperFile: 'src/Backend/OrderService/gradlew'
              gradleOptions: '-Xmx3072m'
              javaHomeOption: 'JDKVersion'
              jdkVersionOption: '1.8'
              jdkArchitectureOption: 'x64'
              publishJUnitResults: false
              testResultsFiles: '**/TEST-*.xml'
              tasks: 'build'

          - task: Gradle@2
            displayName: 'Clients'
            inputs:
              workingDirectory: 'src/Clients'
              gradleWrapperFile: 'src/Clients/gradlew'
              gradleOptions: '-Xmx3072m'
              javaHomeOption: 'JDKVersion'
              jdkVersionOption: '1.8'
              jdkArchitectureOption: 'x64'
              publishJUnitResults: false
              testResultsFiles: '**/TEST-*.xml'
              tasks: 'build'

          - task: CopyFiles@2
            displayName: 'Copy drop'
            inputs:
              SourceFolder: '$(Build.SourcesDirectory)\src'
              Contents: '**/build/libs/!(buildSrc)*.?ar'
              TargetFolder: '$(build.artifactstagingdirectory)\drop'

          - task: CopyFiles@2
            displayName: 'Copy deployment artifacts'
            inputs:
              SourceFolder: '$(Build.SourcesDirectory)'
              Contents: |
                **/deploy/SSH-MRP-Artifacts.ps1
                **/deploy/deploy_mrp_app.sh
                **/deploy/MongoRecords.js
              TargetFolder: '$(build.artifactstagingdirectory)\deploy'
            
          - task: PublishPipelineArtifact@1
            displayName: 'Upload drop'
            inputs:
              targetPath: '$(build.artifactstagingdirectory)\drop'
              artifact: 'drop'
              publishLocation: 'pipeline'

          - task: PublishPipelineArtifact@1
            displayName: 'Upload deploy'
            inputs:
              targetPath: '$(build.artifactstagingdirectory)\deploy'
              artifact: 'deploy'
              publishLocation: 'pipeline'
    
    - stage: Release
      jobs:
        - deployment: VMDeployment
          displayName: "Deployment on local Ubuntu VM"
          environment:
            name: "Target VMs"
            resourceType: VirtualMachine
            tags: web
          strategy:
              runOnce:
                  preDeploy:
                    steps:
                      - task: Bash@3
                        inputs:
                          targetType: 'inline'
                          script: 'echo ''Hello world'''
                  deploy:
                      steps:
                        - task: DownloadPipelineArtifact@2
                          inputs:
                            buildType: 'specific'
                            project: 'daf1bce1-923a-41af-ad31-cfebfd7eda61'
                            definition: '115'
                            buildVersionToDownload: 'latest'
                            artifactName: 'drop'
                            targetPath: '$(Pipeline.Workspace)'
                        - task: DownloadPipelineArtifact@2
                          inputs:
                            buildType: 'specific'
                            project: 'daf1bce1-923a-41af-ad31-cfebfd7eda61'
                            definition: '115'
                            buildVersionToDownload: 'latest'
                            artifactName: 'deploy'
                            targetPath: '$(Pipeline.Workspace)'
                        - task: Bash@3
                          inputs:
                            filePath: '$(Pipeline.Workspace)/deploy/deploy_mrp_app.sh'

The Build stage of my pipeline runs on a hosted agent: I am building the Java services with it. I don’t have a Gradle build server easily available (nor I want to spend the effort of setting up one!), and as it is provided by Azure Pipelines it suits my requirement. Once the Build stage is done, the Release starts. I am targeting the environment I created before (Target VMs), and I am pointing at all the VMs with the web tag.

From there I am using one of the OOB strategies, called runOnce. As the name suggests, it runs once on all the targets, and it has two distinct phases: a preDeploy one, and a main phase for deployment.

The preDeploy phase allows to run specific tasks before the main deployment phase, and it is very useful for setting the environment before the actual deployment. In my case I am running a simple echo script, also because there used to be a bug where the runOnce strategy didn’t run correctly without it. This has been fixed, but I left it out as an example.

In the main deploy phase the pipeline starts by explicitly downloading from a set of build artifacts. It could be the previous phase (it is in this case), but it could also be from other pipelines. It allows you to shape the pipeline in a granular way, effectively. Then it runs a script to deploy the MRP application (as it comes in the original codebase) via Bash. Again, as simple as we are used to.

The task support is exactly the same as the classic UI-based pipelines and the YAML pipelines. What I find extremely interesting is the OOB support for Rolling deployments, which I will cover in a separate post. Canary and Blue-Green will be implemented as well in the future.

Create a build matrix with Azure Pipelines

Tue, 07 Jan 2020 00:00:00 +0000

I was discussing this with a colleague a couple of days ago (if you are reading this, hi Keith!): can we easily build a build matrix with Azure Pipelines?

A build matrix is something that comes out of product-based companies: you have a single code base that you need to build across multiple permutations of operating systems, software versions, etc. Think about the pre-requisites of your favourite PC videogame or your trusted software you carry with you since God-knows-when - each one of them will have a support matrix behind them, dictating if and how you can get support from the manufacturer. It also means that if yoiu end up within these pre-requisites, chances are your problem has already been identified, documented (and fixed!) as part of a regular testing strategy.

You can do that fairly easily with Azure Pipelines - the documentation has got an example. Is it enough though? I thought about digging deeper - not just stopping at the multiplatform side of the story. And everybody knows about my allergy to JavaScript…

With a moderately complex application there are a number of tasks you need to carry on. Take a simple .NET Core application - you need to restore your dependencies for each project you need to build, compile, run at the very least a suite of unit tests, then package your artifacts and upload it for downstream consumption into each environment. Something resembling this, perhaps…

trigger:
- master

pool:
  vmImage: 'windows-latest'

variables:
  solution: '**/*.sln'
  buildPlatform: 'Any CPU'
  buildConfiguration: 'Release'

steps:
- task: DotNetCoreCLI@2
  displayName: "Restore"
  inputs:
    command: 'restore'
    projects: '**/*.csproj'
    feedsToUse: 'select'

- task: DotNetCoreCLI@2
  displayName: "Build"
  inputs:
    command: 'build'
    projects: '**/*.csproj'

- task: DotNetCoreCLI@2
  displayName: "Unit Tests"
  inputs:
    command: 'test'
    projects: '**/tests/UnitTests/UnitTests.csproj'

- task: DotNetCoreCLI@2
  displayName: "Publish Infrastructure"
  inputs:
    command: 'publish'
    publishWebProjects: false
    projects: '$(Build.SourcesDirectory)/src/Infrastructure/Infrastructure.csproj'

- task: DotNetCoreCLI@2
  displayName: "Publish ApplicationCore"
  inputs:
    command: 'publish'
    publishWebProjects: false
    projects: '$(Build.SourcesDirectory)/src/ApplicationCore/ApplicationCore.csproj'

- task: DotNetCoreCLI@2
  displayName: "Publish Web"
  inputs:
    command: 'publish'
    publishWebProjects: true

- task: CopyFiles@2
  inputs:
    SourceFolder: '$(Build.SourcesDirectory)'
    Contents: |
      src\ApplicationCore\bin\Debug\netstandard2.1\ApplicationCore.dll
      src\Infrastructure\bin\Debug\netstandard2.1\Infrastructure.dll
      src\Web\bin\Debug\netcoreapp3.1\Web.dll
      src\Web\bin\Debug\netcoreapp3.1\Web.Views.dll
    TargetFolder: '$(Build.ArtifactStagingDirectory)'

- task: PublishPipelineArtifact@1
  inputs:
    targetPath: '$(Build.ArtifactStagingDirectory)'
    artifact: 'drop'
    publishLocation: 'pipeline'

Now, awesome. But what if you want to support two different .NET Core versions and all the major operating systems, in at least two versions? In a regular scenario, it means either a lot of overhead or a lot of interaction.

The YAML Pipeline facilities come to our rescue thanks to the matrix option in the strategy job condition..

This allows for simple, zero-touch permutations. An example is the one above: two OS, with two runtimes depending on the version:

trigger:
- master

strategy:
  matrix:
    'Ubuntu 16.04':
      image: 'ubuntu-16.04'
      dotnetcore: '2.2.x'
    'Ubuntu 18.04':
      image: 'ubuntu-18.04'
      dotnetcore: '3.1.x'
    'MacOS X High Sierra':
      image: 'macos-10.13'
      dotnetcore: '2.2.x'
    'MacOS X Mojave':
      image: 'macos-10.14'
      dotnetcore: '3.1.x'
    'Windows Server 2016':
      image: 'vs2017-win2016'
      dotnetcore: '2.2.x'
    'Windows Server 2019':
      image: 'windows-2019'
      dotnetcore: '3.1.x'

pool:
  vmImage: $(image)

variables:
  solution: '**/*.sln'
  buildPlatform: 'Any CPU'
  buildConfiguration: 'Release'

steps:
- task: UseDotNet@2
  inputs:
    packageType: 'sdk'
    version: $(dotnetcore)
    
- task: DotNetCoreCLI@2
  displayName: "Restore"
  inputs:
    command: 'restore'
    projects: '**/*.csproj'
    feedsToUse: 'select'

- task: DotNetCoreCLI@2
  displayName: "Build"
  inputs:
    command: 'build'
    projects: '**/*.csproj'

- task: DotNetCoreCLI@2
  displayName: "Unit Tests"
  inputs:
    command: 'test'
    projects: '**/tests/UnitTests/UnitTests.csproj'

- task: DotNetCoreCLI@2
  displayName: "Publish Infrastructure"
  inputs:
    command: 'publish'
    publishWebProjects: false
    projects: '$(Build.SourcesDirectory)/src/Infrastructure/Infrastructure.csproj'

- task: DotNetCoreCLI@2
  displayName: "Publish ApplicationCore"
  inputs:
    command: 'publish'
    publishWebProjects: false
    projects: '$(Build.SourcesDirectory)/src/ApplicationCore/ApplicationCore.csproj'

- task: DotNetCoreCLI@2
  displayName: "Publish Web"
  inputs:
    command: 'publish'
    publishWebProjects: true

- task: CopyFiles@2
  inputs:
    SourceFolder: '$(Build.SourcesDirectory)'
    Contents: |
      src\ApplicationCore\bin\Debug\netstandard2.1\ApplicationCore.dll
      src\Infrastructure\bin\Debug\netstandard2.1\Infrastructure.dll
      src\Web\bin\Debug\netcoreapp3.1\Web.dll
      src\Web\bin\Debug\netcoreapp3.1\Web.Views.dll
    TargetFolder: '$(Build.ArtifactStagingDirectory)'

- task: PublishPipelineArtifact@1
  inputs:
    targetPath: '$(Build.ArtifactStagingDirectory)'
    artifact: '$(image)'
    publishLocation: 'pipeline'

The build component of the pipeline is the same. All I did is adding the matrix on top, and force the explicit version of the .NET Core SDK I want to use for my target build so to dynamically enable different versions.

Let’s take a look at the matrix itself in detail:

strategy:
  matrix:
    'Ubuntu 16.04':
      image: 'ubuntu-16.04'
      dotnetcore: '2.2.x'
    'Ubuntu 18.04':
      image: 'ubuntu-18.04'
      dotnetcore: '3.1.x'
    'MacOS X High Sierra':
      image: 'macos-10.13'
      dotnetcore: '2.2.x'
    'MacOS X Mojave':
      image: 'macos-10.14'
      dotnetcore: '3.1.x'
    'Windows Server 2016':
      image: 'vs2017-win2016'
      dotnetcore: '2.2.x'
    'Windows Server 2019':
      image: 'windows-2019'
      dotnetcore: '3.1.x'

pool:
  vmImage: $(image)

This is an example hence the simple approach - a more engineered approach would be to populate the matrix variables via other controlled variables, without requiring a change in the pipeline in case you want to change the version or the image. No other modification is required, no configuration or extra software to install. It’s all part of the out of the box experience.

The result can be consumed really easily - the .NET Core 2.x version value I entered there doesn’t work on purpose while the 3.x does. This is the build summary for the whole set of runs, with each run clearly marked:

It also means that the effort to add or remove an environment from the matrix is all in the key-value pairs making it up. If I were to make it more complicated by adding both .NET Core versions to each OS, I could have added a template to loop for each one of them with the same image type so to have a situation like:

Windows Server 2019 runs with .NET Core 2.2.x
Windows Server 2019 runs with .NET Core 3.1.x
Windows Server 2016 runs with .NET Core 2.2.x
Windows Server 2016 runs with .NET Core 3.1.x
…

It is a strong display of power for the pipelines as code approach - I am moving more and more things over there, and I see little reasons to go back, smaller by the day.

Review - The Unicorn Project

Sun, 22 Dec 2019 00:00:00 +0000

Here it is, the most awaited book this year for whoever is even tangentially involved with DevOps…

The book covers the endeavours of Maxine, demoted from her team at Parts Unlimited to the Phoenix Project just after the payroll outage. It is set in the same universe as The Phoenix Project and both books share the same timeline.

The Phoenix Project was about the transformation of an organisation to an engineering factory, being able to free from the shackles of legacy and become a true value mover. With that background in mind, The Unicorn Project goes deeper behind the scenes, looking at the people and the human interactions behind the transformation.

We finally get to know the development teams, and how they work with each other. Brent is no longer ‘just’ the technical SME, but he has got a specific role and personality to fit within the team. It all makes sense at the end of the day, you are going deeper hence you discover more about these key people. And we’ve all been Maxine, at some point…

The biggest takeaway IMHO is about the Five Ideals, a long overdue definition over these key processes we long considered best practices. I am not going to spoil anything from the book so this is my own interpretation, but in short they are:

Locality and simplicity
Focus, flow and joy
Improvement of daily work
Psychological safety
Customer focus

They can only be enabled by the Three Ways described in the previous book. And thinking about it, it makes total sense as you need an organisational driver for change before being able to put them into practice.

There are all sorts of situations we’ve experienced in one way or another. From the lack of reliable CI to the outages and the executives’ behaviour, this book is a collection of real people talking about a realistic scenario. it is definitiely a book to get at all costs (together with The Phoenix Project if you haven’t already!), as it will provide a guideline and a blueprint for anyone trying to transform and improve an organisation.

There was one detail I believe spoiled the immersion and the experience: the frequent name-dropping of technologies and companies. It was not there in the Phoenix Project, and I personally didn’t like it because instead of acting as a reminder (I believe that was Gene’s aim) it kinda broke the 4th wall too often. I didn’t mind Parts Unlimited to sit in its parallel universe, without FAANG and references to various pieces of technology.

It’s definitely a minor detail that won’t ruin your enjoyment of the book, but for me it was a noticeable difference from the first one.

Why isn't my agent updating?

Fri, 13 Dec 2019 00:00:00 +0000

This happens fairly often in restricted configurations where there are proxies, firewalls, etc… Let’s say you want to update your Azure Pipelines agent from the UI:

If you see a message saying that it’s downloading the agent and then goes back to Idle, chances are you have a networking issue on the agent machine, usually towards the internet.

The agent update process is fully automated, and all it does is downloading the new agent from a well known address (https://vstsagentpackage.azureedge.net), and replacing the binaries.

Go and have a look in the Agent log:

You can see that the machine cannot download the new agent package, hence the process fails and releases the agent from the lock to bring it back to the pool. It’s a totally safe operation, but you won’t see any error message surfacing in the UI by design.

You've got no excuses in managing secrets with Azure DevOps and KeyVault!

Sun, 01 Dec 2019 00:00:00 +0000

As part of a solid engineering practices one of the first things I flag up during an assessment is how you handle secrets - their management is really one of these things where you cannot cut corners.

Azure KeyVault is awesome in this, as it is really set-and-forget. And using Azure Pipelines with KeyVault is really stuff of the dreams, as the integration between the two makes it really easy to consume.

Let’s say you setup this secret named ‘Key’ in KeyVault:

Azure Pipelines and Azure KeyVault by default share a convention over configuration approach, meaning that your secrets’ key names in a KeyVault are automatically mapped to Pipelines variables with the same name. This makes it ridiculously easy to use!

All you need to do is to download the secrets you are interested in from your KeyVault as part of a build or a release, and use the relative variables.

In the real world you would use it to deploy and configure your resources, but I didn’t want to add additional overhead to the scenario - I just want to show you that it works.

So I created a quick Pipeline that validates a secret with a control value to make sure it is correct - the Key variable is empty but encrypted to mark it a secret, the ControlKey variable is the value against which I want to check it:

Then this barebone PowerShell script is going to validate it on the fly:

Give it a go, I can guarantee it is going to work as expected :-)

Enforce governance on Azure DevOps Organisations

Wed, 20 Nov 2019 00:00:00 +0000

This is a crucial but often overlooked detail when it comes to corporate adoption of Azure DevOps - how can I prevent users from creating rogue Organisations?

Needless to say, the first port of call would be to understand why the rogue Organisation was created in the first place. Talking to each other goes a long way! And more often than not, the underlying reason is a simple misunderstanding of requirements or a lack of communication betweem two parties. The main reason why Organisations should not proliferate is because it can easily become a governance nightmare - especially when you start connecting Azure subscriptions.

While there is always a chance of someone creating an org with their own personal Microsoft Account (nothing you can do about that I’m afraid!), we have some options to track or even prevent Organisations created with AAD backing but without approval.

The reactive route is fairly easy to implement: you can setup an Azure Monitor Alert looking for operations against the Microsoft.VisualStudio/Account Resource Type:

This will alert you if someone creates a new Organisation connected to an Azure Active Directory tenant. It is good, but it is still reactive: someone did it and now you have to fix it.

The proactive way has just been released - the documentation is here, and the role looks like this:

The new Administrator Role, that is going to contain a list of authorised users, is combined with a feature which ties-in with your existing Azure DevOps Organisations:

These two together prevent the creation of unauthorised AAD-backed Organisations, and simply the overall governance of the stack. Fewer operations to worry about!

Did you know? Repo branching policies in Azure DevOps

Wed, 13 Nov 2019 00:00:00 +0000

It’s one of these things that go unnoticed until you actually stumble upon them: did you know that Azure DevOps has a number of branch policies you can apply to each repository in your Team Project?

These are repo-wide, different than the ones specific to the single branch. I am very fond of the Commit author email validation one that blocks lazy people not setting up their Git Config correctly :-)

It’s also very handy to be able to control the maximum file size and path length direcly:

Check them out, I am sure you will find an excellent use of these. Small details, but they can make the difference sometimes.

When to integrate SCA?

Fri, 01 Nov 2019 00:00:00 +0000

As much as I am a fan of Microsoft Secure Code Analysis I would not go and blindly integrate the whole suite without a degree of thought.

If you attended one of the sessions where I talk about quality, as part of my common sense approach to blending security concepts into the DevOps fabric of an organisation I still swear by nimbleness and agility - meaning I am not going to transform a 30 seconds build into an ordeal. We are in luck with SCA though, as most of the tools bear a minimal overhead so we can integrate as many as possible into a CI build!

That said, still think wisely about how you are going to implement the toolkit: stuff like CredScan or BinSkim should always be integrated in a CI build. BinSkim slows things down a little bit, but the benefit of that is that every binary vulnerability will be raised immediately rather than after a PR or a merge. It is worth it - you don’t want to spend more time fixing a develop build!

On the other hand a full-blown malware scan (maybe with a boot sector scan as well), with a large set of artifacts can take a long time and you might not want to run it in a regular run-of-the-mill build. The place where this is mostly needed is towards the final stages, where you are preparing these bits for consumption.

The Roslyn Analysers and TSLint are very much an extension of what you can do in your IDE (more to come on that) and the overhead is similar to a local build - the impact varies massively depending on the rules you decide to apply. It’s a call you make on the balance of things, and you have alternatives like SonarQube that can help swing the decision.

Getting started with Secure Code Analysis

Tue, 22 Oct 2019 00:00:00 +0000

I recently got in touch with the Microsoft Secure Code Analysis team as part of my deeper research on DevSecOps practices, and I was astounded by how easy and effective it is to integrate a decent baseline of Continuous Assurance into any pipeline.

If you want to give it a go send them an email, they have a two weeks trial you can leverage to evaluate the solution. I strongly encourage you to do so as it is so easy to get it into your existing pipelines!

Once you get access to the extension it gets really straightforward to implement - you add the extension to your Azure DevOps Services instance and you are good to go. Unfortunately it does not work on-premise.

These are the tools you can add - with the exception of the Microsoft Security Risk Detection (which requires an account on the MSRD service) everything else is a simple task in the pipeline:

Now, a few tips on this: if you want to have full status integration with the pipeline you need to add that Post Analysis task. The tools are designed to use in a non-obtrusive manner, but it is my personal recommendation you start adding that as a success condition. You can even decide which tool to independently use as a success condition:

Let’s take the Credential Scanner as a starting point. It is essential. As a rule of thumb, if you can, you should always have a CredScan in your CI builds. It’s one of these things you should never skip IMHO… It cannot be any simpler to run. Choose an Output Format and point it at any folder you like - usually the source code directory will do.

If credentials are in your source code (the horror!) the build will eventually fail - and if you upload your output file to a drop folder you will also be able to see where are these!

This is just a taster, in the coming posts we will look at more tools and at a few integration strategies.

Review - DevOps for the Modern Enterprise

Sat, 19 Oct 2019 00:00:00 +0000

It’s been a while since my last book review - unfortunately I did not read any work-related book for the last few months, and that dried up a fair bit.

That said, I just finished Mirco Hering’s DevOps for the Modern Enterprise and I think it is a great one.

It’s a very good book for several reasons, but the one that resonates the most with me is that all the mentioned approaches and situations are definitely from the real world: I’ve been through similar scenarios and I am facing some of them even right now.

Stuff like the use of the strangler pattern for org-wide applications reviews for example, it’s something that is really tried-and-tested - or on how to manage the relationship with your team (resources, a term neither of us really get on well with). I am sure anyone in a management position will find benefit from that, and there is also a nice section at the end about the technology trends and aspects that are getting traction these days. It is really a nice all-around view on real world DevOps and Continuous Delivery.

That said the book goes way beyond the traditional DevOps angle, and Mirco is very good at widening the angle at which he is applying the suggestions. From a technology perspective, the book defines regular patterns you can apply to a variety of situations, and it is very broad in reach so anybody can find something valuable out of these pages. It’s very much a collection of advices coming from real life examples, for the good and the bad. I can really recommend it.

When to scan what?

Thu, 10 Oct 2019 00:00:00 +0000

Picking up from my last post, a question I regularly get after showing these tools is:

Should I apply all of these (tools and practices) to CI builds and canary releases?

The answer is clearly not. If you start running code quality checks, SASTs, DASTs, OSS compliance checks SVTs, etc. as part of a CI process these will become ridicously long and the value you think you are providing will go down the drain, lost in the sea of people screaming because your CI build now takes four hours up from the two minutes it used to.

Everything clearly has a place and a time.

There are no-brainers like OSS compliance scans for example - these should happen at every CI build. Doing it so early prevents the risk of adding an old/insecure/non-compliant library and causing issues down the line. Also, the overhead on the build process is minimal - we are talking a couple of minutes tops (from what I’ve seen).

Secrets detection is another one: you cannot afford to leak a password, access key or whatever other secret these days. It doesn’t need more time spent on it.

Other things like code quality scans are more nuanced. My approach to these is to have different rulesets for different type of builds. A CI build to develop will have a different (looser) ruleset compared to a full master release. And it makes sense - if you want to merge a large development from develop to master for the first time chances are you focused on certain areas of the enhancement, which while being absolutely good and welcome it might cause issues within master. Different rulesets ensure you don’t get bogged down in making it green from the beginning, but you can spend time on these refinements closer to the moment you actually need to merge it.

Infrastructure deserves its own chapter. Security Validation of IaC resources should always be a continuous process, because it is subject to continuous movement. Take IaaS for example. OS patches are enough movement to demand for a continuous process, without mentioning infrastructure vulnerabilities (even at network level). DevOps is simply the entrypoint for this practice - it is imperative to make it an organisational approach.

If you run Security Validation Tests regularly on your infrastructure, you will find out things that are usually brought up only on demand:

Doing so will not only save you a massive headache, but it will ensure you are going to proactively act on these areas rather than fixing things in a rush as a reactive effort. And this saves money in the longer run. Different security rules and analysis (again) at every step of the way - IaC analysis at build and release time, but then continuous assurance at structural level, as a separate process from the development workstream.

It is also connected to Security scans - both static and dynamic.

A SAST (Static Analysis Security Test) is expensive to run - it can take hours to complete a run. A DAST (Dynamic Analysis Security Test) alone might not be enough. Having a structured chain of checks and balances, with different tools, rules and layers along the way from the IDE down to the Production environment is going to make all the difference in the world when it comes to DevOps.

SASTs should be performed in parallel to all the other testing activities. DASTs can be run as part of the performance and reliability testing.

This mix ensures a good level of agility for delivery (you still need to deliver your value as per DevOps definition!) while balancing it with a strong, 360 degree approach that ensures no stone is - hopefully - left unturned during the journey.

Integrate Fortify in Azure DevOps, how easy!

Mon, 30 Sep 2019 00:00:00 +0000

For my latest session (at WinOps 2019, brilliant conference as usual) I dabbled with some addition to my session on Code Quality and DevSecOps.

One of these additions was Fortify - a well-known security scanner from Microfocus. I played with their On-Demand offering, and I was amazed at how easy it is to setup. There were a couple of catches I want to mention though.

Bearing in mind a security scanner in a Pipeline simply sends the code samples to the service, I was expecting it to be smoother to configure. Nothing hard, undocumented or complicated, but there are a couple of things that might require clarification.

For example, creating a BSI token. A BSI (Build Server Integration) token is something used by Fortify to identify the application and the build server used as a gateway. All is nice and good, but when I tried to configure the token directly from the Azure Pipelines suggested link I only got as far as a login error goes.

On the other hand, doing the same from the Application Dashboard worked a charm.

Also, the task itself - don’t expect anything other than a green build if it all goes to plan:

There is no dashboard integration within the build or any other sign of communication between the two. That said I am not expecting CI builds to include this scanning tool so it might be understandable.

All in all the tool is very nice though. Something I particularly enjoyed is seeing the level of detail it can go. Let’s take this simple issue:

Not only you will get a technical explanation with a safe example, you will also get a list of all the best practices and standards (including GDPR) you are violating:

I reckon it is a very valuable information to have in this day and age. Just don’t integrate it in the CI build (but pass it along onto master and develop) as otherwise you won’t be able to appreciate its value.

Let's talk about Build retention, shall we?

Sun, 15 Sep 2019 00:00:00 +0000

Build Retention Policies have always been a contentious thing to talk about: at some point, you need to let go of your old builds. This post is not about after how long, but to talk about a couple of things to consider which might not be immediate.

Retention policies are applied at project level:

You have three settings to think about: how long you want to keep your artifacts and attachments, your runs and your pull request runs. A run is the actual build run, and it overrides both the other settings:

You can keep a run for up to two years, but artifacts and attachments will be gone after two months and PR runs after one. This is the topmost setting you can have, and it makes sense at the end of the day: you don’t want to clog your organisation with stuff that is effectively not useful in the longer run. If you want to store your artifacts for more than two months you should publish your artifacts in a proper way (Azure Packages springs to mind…) rather than relying on the build run.

Then the elephant in the room: how should I version my build runs?

Long story short, you should have a way of easily identify your builds. It can be GitVersion, it can be Semantic Versioning, it can be something else…but don’t leave them to the standard naming convention as it won’t make your life any easier.

Do not rely on the $(Rev:r) counter - you need to be in control of your builds, and be able to come back to a certain build if needed. Using $(Rev:r) isn’t a feasible solution in the long run and also, bugs might hit. I was affected by this one, and there was no way back.

Project-wide flaky test detection

Thu, 05 Sep 2019 00:00:00 +0000

Azure DevOps is a complex platform and today I found out something quite interesting: system-wide flaky test detection.

A really neat feature indeed - you can configure detection and management of flaky (unreliable) tests so that it does not affect the overall statistics of your code quality analysis.

In my opinion this feature shines when your tests are under development, and they are not yet finalised in your codebase. With it you can have a reliable picture with the stable tests as part of the test reporting side of the build, and these tests under development will be left on the side to allow for analysis and fixes.

Of course you have total control over what is recognised as Flaky/UnFlaky, as per this documentation screenshot:

You can always change the category and alter the build result.

Hey, my Service Principal expired!

Mon, 19 Aug 2019 00:00:00 +0000

If you used Azure DevOps long enough, you will eventually run into a situation like this - your Service Principal will expire and throw this error:

Don’t panic if you see this - when you authorise an Azure Resource Manager Service Connection Azure DevOps creates a new App Registration in Azure Active Directory (even if you are using as public tenant like hotmail - you will still get an AAD tenant to use):

This App Registration has a default expiration of two years:

The error simply means that your Service Principal expired. All you have to do is to renew the Service Principal from the Azure DevOps UI and you will be good to go. Don’t renew it from the Portal, as otherwise Azure DevOps won’t know how to handle the secret!

Challenges of creating an internal sharing model with Azure DevOps

Sat, 10 Aug 2019 00:00:00 +0000

Azure DevOps is a brilliant platform with a flexibility second to none, so it comes fairly natural to try and push its boundaries more and more when you start experimenting with its feature.

A very interesting problem came up in the last couple of weeks:

I am trying to create an internal sharing model (also known as Inner Source) within our Azure DevOps organisation, but I am stuck on the visibility front. How can I make sure that users of different, segregated projects all get access to the same, shared project?

It is an interesting situation indeed. And guess what, it all boils down to a couple of points.

Looking at the individual services, everything looks so easy - the easiest to tackle is Azure Pipelines - cross-Team Project consumption is trivial to setup, so that is definitely off the problems’ list.

Azure Repos itself, not an issue - it is a Git repository after all, and features like Forks make this a very valuable component. Each user will be able to fork from/to the shared set of repositories in a completely transparent way.

Azure Test Plans…nothing to mention, really.

Azure Boards has got an interesting challenge, which highlights the most complex problem you will face in this exercise: you cannot re-use existing Project Groups nested into different Groups. This throws a massive spanner in the works, as if you are creating an Inner Source model you don’t want to handle permissions at a granular level, but you want as much inheritance as possible when it comes to accounts. It doesn’t make sense to authorise a user directly, expecially if you have a large organisation - the management overhead becomes quickly too much to handle.

You also cannot take the shortcut of leveraging the Project Collection Valid Users group - that is locked down, and unless you start fiddling with tfssecurity.exe. You can do that, but what stops me (and should stop you) is that you are forcing a group you are not supposed to use. It can work, it works, but from a supportability point of view it can become a risk - and if you have a very large organisation I am not sure it is the best way forward.

So, what are we left with? Aside from adding users directly (again, no!), if the organisation is setup in a smart way you will likely have your AAD synchronised with an on-premise Active Directory forest. That means your AD groups can be leveraged in Azure DevOps, and the users contained in there will inherit the access permissions.

With that in mind, you can build your Inner Source security model around AD groups (which should already control user access, as Active Directory - or any other directory service for this matter - should be the main way of handling access) mapped to Azure DevOps prather than directly into the Team Project, and then assign the group(s) to the Inner Source project.

Of course it is not something you will do for every organisation. If you have small organisations you might accept managing the users. If you are using a single Team Project, you don’t have this problem at all. As usual, the real world is the most varied of the demo scenarios, there is no one-size-fits-all solution.

What is the difference between Usage and Auditing in Azure DevOps?

Sun, 28 Jul 2019 00:00:00 +0000

The Azure DevOps team released a new Auditing feature a couple of days ago, and then a question immediately sprung up: what is the difference between Auditing (the new feature) and Usage?

Usage is pretty much the old Operational Intelligence brought into a new UI and into the Cloud operating model: it is mostly about service health, and from there you can only get a live snapshot of what is going on. Data is flushed after 14 days and lists every call to the APIs. It can be used as an auditing tool, but it is not meant as such - you need to spend time filtering the log and extracting the information you need to get to a point where you can use that data for an audit. I blogged about this in the past.

Auditing is much more - it is a centralised place for events raised in Azure DevOps. An event is an access policy change, a Team Project creation or deletion, extension installation or update, etc. It provides a much different view over what happens to the service, and it is tailored down the needs of a real auditing process - it means no more fiddling with the log, no more overhead to extract the data you need.

The feature is currently under development, and it is going to receive interesting developments like this one.

Why are you not using conditions?

Sat, 20 Jul 2019 00:00:00 +0000

All technology tools and platforms have some feature which, for one reason or another, are less known and used compared to others. More often than not, Conditions in Azure Pipelines fall within this category.

Out of ten Pipelines I see on any given day, at least eight will have everything chucked in a single Job. It is definitely not an optimal way of doing things.

Aside from the fact that Jobs are there for a reason (I might talk about this next time around) what shocks me the most is that people will come with the most convoluted ways to achieve what is effectively a trival goal given the right tools.

For example, let’s pick up an extremely common, simple yet very hard example: a database backup to run before running the pipeline.

Yes, if the database is a reasonable size it can be embedded somewhere. But what if it isn’t? In that case, you should think long and hard about it. How long will it take? Are you going to slow down your releases? Shall we start adding an extra stage before just for that?

Stop you there for a second. Do you need to run a backup every time? That alone is an answer that shapes the pipeline design. If not, then you need a Job that runs the backup only under certain conditions. Conditions you control.

So, the database backup should not run by default, but it needs to be controlled when releasing. Easy peasy - first of all, create a scoped variable for each stage where this applies:

This variable controls our Job. Then the job needs to be configured to look for the value and act accordingly.

That’s literally it. Set the variable when triggering the release, and you are set:

Features are there, documentation is plentiful, use them! :-)

How to implement rollback strategies in Azure Pipelines

Sun, 07 Jul 2019 00:00:00 +0000

Sometimes simple things seem really hard - rollback strategies seem to end up in this category!

Let’s make things simple: each and every release pipeline you create can have multiple jobs, and each job can have its own execution condition.

This means you should have, at a minimum, one job for your deployment and one for your rollback if something goes wrong:

The Rollback job will have this execution condition:

There you can run everything you need to restore your target stage - drop a database and restore it from a backup for example, together with an artifact rollback. Do not use a separate stage for this, as it creates confusion and potentially problems. Always add a rollback job at the end for this purpose.

And eventually, this is clearly true for both cloud and on-premise scenarios - there is nothing stopping you from doing this regardless of the target location. In case of an on-premise deployment you would use a Deployment Group job rather than an Agent job, that is the only difference.

Ten years of MVP Award

Mon, 01 Jul 2019 00:00:00 +0000

Today is an important day. Today is Renewal Day for a sizeable amount of the Microsoft MVP population, and I was renewed as well for the 10th year in a row.

Ten years is a very long time…why do I keep doing everything I do (which eventually can bring to the Award, but never the other way around)? Because I love it.

I love running a Meetup, despite massive drop rates and a perennial struggle for attendance. I just organised Global DevOps Bootcamp 2019 in London, which was a huge experience. I just love meeting people and listening to their experience while sharing mine, over the years I became friends with a huge amount of people, and being an MVP became an enriching experience at a deeply personal level.

I am a founding member of several other communities all over Europe, and I travel at my own expense (except if the conference has paid for tickets!) to speak anywhere I can find a stage, large or small. I do it because I believe that sharing is the cornerstone of cultural growth, and I try to venture in new territories whenever possible. It is also an excellent excuse to travel and visit new places :-)

I started my first few open-source contributions this year, and I hope I will pick them up again whenever I have time. I have a huge mountain to climb in that regard, but I am not giving up on that…it is still part of the sharing concept above.

All in all, it’s been a fantastic ride. Let’s turn this corner, and keep going.

Remember the power of an Agent

Sun, 30 Jun 2019 00:00:00 +0000

This post stems from a discussion I had a few days ago: sometimes we just forget how powerful having an Agent on a target system can be.

The example in case is for a well known financial product, which usually runs in a network isolated from the internet and with very limited access from operators. You want a degree of controlled access without resorting to complex solutions (AAD Conditional Access, etc.) or products because of other limitations. You cannot leverage Azure Automation as well with its Hybrid Runbook Worker because of the non-existent internet access. What’s left?

Enter Azure DevOps Server in this scenario. Once you install an Azure Pipelines agent on the target machines you have an easy way of leveraging all sorts of automations (including custom scripts if you really need them!) in a tightly controlled fashion. Once the permissions are clearly locked down (and approvals are in place at every required stage) you can use the linked Git repositories or TFVC paths to drop whatever you need on the targets, automate routine tasks, perform scheduled operations.

You get the authentication layer for free, courtesy of Active Directory. You get an integrated artifact funnel thanks to either Repos or Artifacts. You get several out-of-the-box ways of performing automated tasks and you get an orchestrator to coordinate these tasks.

If you think about it from a non-technical point of view, how much effort would it take to build up something like that from scratch or integrate a number of different technologies to do all of the above? A lot, I reckon. Which is why one should never forget the power of an Agent :-)

Postmortem of the Global DevOps Bootcamp 2019

Sun, 16 Jun 2019 00:00:00 +0000

This year I hosted the Global DevOps Bootcamp 2019 for London, and the theme of the event was You Build It, You Run It! - so it’s time for a postmortem!

It was a wrap-up of several months of preparation, not only from myself but also from the central organisation team. The effort they put in was really remarkable, and I don’t think we would have gone anywhere without their support. What they did was really outstanding, not only from a technology standpoint but also on the operations side - I never saw anything being that smooth from top to bottom.

The event itself went really well: six teams were extremely engaged with the challenges and they spent the whole day in the awesome Microsoft Reactor:

The whole premise of the workshop was about maintaining a production website (Parts Unlimited!) up and running so that sales could keep coming in - that was a brilliant way of keeping people on their toes, with each team using a different approach to maintain it up as much as possible. The clear takeaway here was about acting with pro-activity: many of the problems introduced during the challenges could have been prevented by implementing pro-active strategies like monitoring, alerting or other pre-emptive actions in general.

The most recurring feedback was to get the challenges available as either documentation or samples after the event, something that I believe it is going to happen down the line.

In terms of what did not go well, unfortunately it’s all about the drop rate and the no-shows. I managed to send back pretty much of the no-longer-needed lunchboxes so I could minimise waste, but as of today I still cannot get my head around how it is possible being unable to cancel the participation to a free event as soon as you are aware of another commitment (and despite reminders!). It doesn’t take much after all, and it hurts future possibilities of organising similar events. One of the attendees told me that his friends gave up on rocking up on the day because of the sold-out capacity, which we were nowhere near on the day.

Regardless, I loved hosting the event and I am surely looking forward to hosting next year’s as well at the London Microsoft DevOps Meetup!

Review - Azure DevOps Server 2019 Cookbook

Wed, 05 Jun 2019 00:00:00 +0000

More than ten years ago I was at the beginning of my career, and I bought a book - “Team Foundation Server 2008 in action”. That book was a cornerstone in cementing my future as an ALM and then DevOps expert, and it was massively different compared to the vast majority of other books available at that time because of its setting: a series of targeted examples, easy to implement and with reachable value. I loved that book, and I never gave it away - I still rock it in my personal library together with many others.

Fast forward a good twelve years later, you can imagine that when my colleagues Tarun Arora and Utkarsh Shigihalli told me they wrote a new edition of their Cookbook on ~~Team Foundation~~ Azure DevOps Server me buying it was simply a natural consequence. As you can see from the post history, it’s been a while since I blogged a review - for good reason. I did not stop reading, I simply did not find an extremely good book to talk about, and I did not want to have another outlet for moaning about things :-)

This one is different. I feel long gone are the days of both extremely detailed, deep dive books and shallow, introductive texts. The former have been replaced by on-demand trainings, the latter by videos and blogposts. These days you don’t find a middle ground that often. This book is that middle ground.

With this book you will have a number of recipes you will be able to implement in a very simple and straightforward way, with immediate impact across teams and organisations. Do you want to do stuff with Git hooks? Chapter 2. Integrate SpecFlow in your pipelines? Chapter 5.

Easy, and handy. I loved it.

How to move your Release Definitions to YAML today!

Thu, 23 May 2019 00:00:00 +0000

You might have got it - I am very, very keen on YAML Build and Release Pipelines, because they unleash the power of a full-fledged orchestrator in a single format: YAML files.

A friend of mine is very excited about them, but he is puzzled by the fact that the Environments page only shows Kubernetes resources. While there is clearly a focus on Kubernetes, this does not mean that you can only use multi-stage CI/CD definitions with it. You can definitely convert your existing pipelines, targeting your current applications!

Let’s take a simple example: a Build Definition that creates a MSDeploy package and a Release Definition that consumes the Build Artifacts and deploys an ARM template and the aforementioned package. You surely saw some tutorial or example on how to achieve this in UI-based (a.k.a. Designer, Classic, etc.) Pipelines, but how to do the same with YAML?

First of all, this is all contained in a file - I am simply going to look at different portions at different times. You can also split them, but for the sake of simplicity I am going to use the whole file as a baseline.

stages:
  - stage: Build
    jobs:
    - job: Build
      pool: 
        vmImage: 'vs2017-win2016'
      steps:
      - task: NuGetInstaller@0
        displayName: 'NuGet restore'
        inputs:
          solution: '**\*.sln'

      - task: VSBuild@1
        displayName: 'Build solution'
        inputs:
          vsVersion: 15.0
          msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.stagingDirectory)" /p:IncludeServerNameInBuildInfo=True /p:GenerateBuildInfoConfigFile=true /p:BuildSymbolStorePath="$(SymbolPath)" /p:ReferencePath="C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\Extensions\Microsoft\Pex"'
          platform: 'x86'
          configuration: 'Release'

      - task: CopyFiles@1
        displayName: 'Copy Files'
        inputs:
          SourceFolder: '$(build.stagingDirectory)'
          Contents: '**/*.zip'
          TargetFolder: '$(build.artifactstagingdirectory)'
      - task: CopyFiles@2
        displayName: 'Copy Files'
        inputs:
          SourceFolder: '$(build.sourcesdirectory)'
          Contents: '**/*.json'
          TargetFolder: '$(build.artifactstagingdirectory)'

      - task: PublishPipelineArtifact@0
        displayName: 'Publish Pipeline Artifact'
        inputs:
          artifactName: 'drop'
          targetPath: '$(build.artifactstagingdirectory)'

This is our Build stage. Nothing too fancy - we use a Windows Server 2016 with Visual Studio 2017 Agent VM provided by the Microsoft Hosted Build Pool, and there we run the usual suspects: NuGet restore, Visual Studio Build, Copy two types of artifacts in the Artifacts Staging Directory and then we use the new Publish Pipeline Artifact to publish the drop folder. This new task is made with YAML Pipelines in mind, and it is definitely the recommended one to use.

Now you need to consume the Artifacts. You can do this in the Deployment stage:

  - stage: Deploy
    jobs:
    - deployment: DeployWeb
      pool:
        vmImage: 'vs2017-win2016'
      environment: 'target'
      strategy:
        runOnce:
          deploy:
            steps:
            - task: DownloadPipelineArtifact@0
              inputs:
              artifactName: 'drop'
              targetPath: $(System.DefaultWorkingDirectory)
            - task: AzureResourceGroupDeployment@2
              inputs:
                azureSubscription: 'ACME Azure'
                action: 'Create Or Update Resource Group'
                resourceGroupName: 'Demo'
                location: 'West Europe'
                templateLocation: 'Linked artifact'
                csmFile: '**/FullEnvironmentSetupMerged.json'
                csmParametersFile: '**/FullEnvironmentSetupMerged.param.json'
                overrideParameters: '-WebsiteName PULE2E -PUL_ServerName PULE2EServer  -PUL_HostingPlanName PULE2EHP
                deploymentMode: 'Incremental'

              ...other stuff to deploy database and web server...

The cool part here is that you can use the same file, and the same language to perform the operations you are accustomed to. If you (like me!) need help with the YAML syntax, use the YAML Assistant and it will take a mere five minutes to get to the results you need.

The graphical result you can see in the whole run is this:

In this case, it is going to be only two stages. Needless to say that if you have more, you will have more (hopefully green!) boxes. And if you need them, you can also have multiple jobs within a single stage. It’s all about what you put in the YAML definition. This is an example with three stages, one job each:

  - stage: Deploy1
    jobs:
    - deployment: DeployWeb1
      pool:
        vmImage: 'vs2017-win2016'
      environment: 'target1'
...
  - stage: Deploy2
    jobs:
    - deployment: DeployWeb2
      pool:
        vmImage: 'vs2017-win2016'
      environment: 'target2'
...

How YAML pipelines change the whole CI/CD story

Fri, 10 May 2019 00:00:00 +0000

At Build the Azure DevOps team announced YAML pipelines for the deployment side of the story. I am very excited, because I believe this changes the whole CI/CD proposition not just for Azure DevOps as a platform but in a broader sense.

For years, I’ve been talking around at conferences and meetups about the fact that in a true DevOps world we only have to deal with packages (coming out of builds) and orchestrators (handling deployments). The whole concept of Build or Release Definition has been slowly merging, and now we are at a stage where we can see a truly unified orchestration story.

So, if in the past you were used to this:

now you need to get used to this:

The fact is - the division is going away. It was already close to non-existent before with the task-based model, but now it is completely gone. To take advantage of this, all you need to do is structuring your yml pipeline as follows:

stages:
- stage: Build
  jobs:
  - job: Build
    pool:
      vmImage: 'Ubuntu-16.04'
    continueOnError: true
    steps:
        ...
- stage: Deploy
  jobs:
  - deployment: DeployWeb
    pool:
      vmImage: 'Ubuntu-16.04'
    environment: 'target'
    strategy:
      runOnce:
        deploy:
          steps:
            ...

The actual result of this pipeline is two stages: one dedicated to the build and the other one targeting a release:

And the two jobs reported in the matching stage:

Of course the example is very simple and does not cover all the possible scenarios, but what this means is that you have an end-to-end pipeline definition from build to release - in different phases, defined by the type of activity you need to perform.

In a real-world situation, one of the things you can do is to split the Build and Release portion of the definition with templates, and pick it up from there. Then the orchestrator will instantiate whatever is needed by leveraging parameters, and you will not only get consistency but also the ability of re-using loads of work in a series of standard components.

Solving the looping problem in Azure DevOps Pipelines

Sat, 04 May 2019 00:00:00 +0000

What should you do if you want to have a Pipelines job that loops based on dynamic inputs? Working around this problem has always been a pet peeve of mine - luckily today we’ve got options! Three in total to be precise, with different degree of difficulty.

One of them is the simplest and has been around for ages: embed what you need to do in a script. Try to split the problem down to the lowest common denominator, and run the script. I just did this in a situation where we needed to run a non-predictable number of SonarQube scans as part of a CI build. We had the whole codebase in the branch (because reasons…), and based off the standard folder structure used by the projects I put together a script that runs the SonarQube scanner based on the number of plugins changed in a certain commit.

If you think about that, it’s a very basic challenge. The problem (I don’t even want to call it as such, but still a challenge regardless) is that there is no built-in facility for such a concept, hence I had to improvise.

The second one is using a build definition to be used as a template. You can trigger a dynamic number of these from another build (with a REST API call) that acts as orchestrator. This is slightly harder, but it allows for the GUI-based definitions to be used as templates so you can re-use what you have and you know already.

The third (and better) way of doing so comes with the YAML pipelines: the each expression.

Each in YAML is equivalent to a for loop. So you can create a template which will have a set of actions, and pass parameters across during your build. YAML is looser than a GUI-based build definition IMHO, so it allows for something like this:

template.yml:

azure-pipelines.yml:

Doing this will create two inline script task totally on the fly:

It is a very elegant solution that solves the looping problem in the first place, but of course it has a steeper learning curve.

Regardless of what you choose, the flexibility of the platform is at such a level that anybody can find the solution which fits best given a problem. And it was good fun exploring them throughout :-)

Make your life easier with Group Rules in Azure DevOps Services

Mon, 22 Apr 2019 17:12:00 +0000

This is something that comes in very handy - licence management isn't the simplest thing to implement and police. There is always someone who is going to try and sneak around the process in place, in order to quickly get access.

Group rules make this really simple. It's basically a templating model applied to the Azure DevOps licensing system:

In the example above, I created a rule for a fictitious Workshop - all my users will have a Basic licence (as they might not be Visual Studio subscribers) but they will be automatically added to the Project Administrators group.

This might feel simplicistic, but you can add as many projects as you like in a rule. Which means that creating these will help shape the organisation's management, especially in large companies - you can have Visual Studio subscribers automatically added to all projects, and Basic subscribers (which might be contractors for example) scoped to business unit (where costs are usually accounted for and split) for example.

If you are an Organisation Administrator, this will save you plenty of time 😁

Do you want to move to YAML pipelines? Here is how I would do it.

Thu, 11 Apr 2019 19:42:00 +0000

YAML pipelines can be daunty, no question about this - especially if you come from a background where you come from a nice UI like the one for Build Pipelines to a plain text file describing the Pipeline itself.

Well, I feel it is daunty anyway :-)

But in a process of continuous improvement I am prone to leave the comfort zone to experiment, and this is how I feel after approaching YAML pipeline. It's a bit like Git, if you like...

So, first of all don't try to mix and match the two - always start afresh. It is double the effort to try to apply something like this in a brownfield situation. Be confident with it first, and then apply it to something else.

Once you remember that the file needs to be named azure-pipelines.yml...my best friend in this process is the YAML schema reference, it contains lots of useful examples to help you structure the pipeline and it contains the references to Bash, Script and PowerShell so you are not completely lost when you approach the task catalogue.
The documentation is now YAML-first, so it is going to be easy to follow. Start by replicating a simple .NET Framework build from the UI with YAML. Then try again with a small variation. You will quickly get the grip with it.

But it is long and tedious and time consuming. Which is why Microsoft decided to create the YAML assistant, a brilliant feature that merges YAML pipelines and the old UI-based designed.

If you need to add a task and you are not sure on what to do, show the assistant and select the task from there:

And you will be able to fill all the parameters like you would in a UI-based pipeline:

Once this is done, add it to the pipeline and you are done with it:

This is a very smart way of handling this, and over time you will find yourself going more and more to it.

Use Azure DevOps Release Gates to check for website availability and automate stage flows

Wed, 20 Mar 2019 19:41:00 +0000

Modern deployment patterns rely on automation, everywhere. A common request in this space is to automatically verify if a web resource is up and running before proceeding with the deployment.

Instead of having a script that runs within a Stage, why not leveraging Release Gates? At the end of the day they are designed with automation in mind.

To make this example generic enough, I created an Azure Function (code here) based off the HttpTrigger sample that checks for a URL availability. If the code is not 4xx or 5xx it returns a simple JSON output:

It is not the coolest or cleanest code, but it works 😁 Now, once this Function is up and running, we can leverage it within a Release Gate in a Pre-deployment condition:

Set the Completion event to ApiResponse, and check the value of the output as a Success criteria. If IsUp is true, then the website is up and running:

You can actually make it even smarter by checking for both IsUp and the code:

This would be enough to have the check in place, and automate the gatekeeping of your stage flow.

Did you know? Changing default and comparison branch in Git from Azure DevOps

Thu, 14 Mar 2019 19:31:00 +0000

This was one of those things you never realise until you actually look at it:

Have you ever thought that many people just leave that at the default setting (both Default and Compare on master) without too much thought?

Well, it is easy to change for both.

Compare:

Right click on any other branch, and select Set as compare branch.

Default:

From the Repository settings, right click on any other branch and select Set as default branch.

Now, you might wonder why you might want to change these settings.

The Compare branch is a user setting - you might want to use it to set your development branch as a baseline branch to see how far master is ahead or behind compared to develop, for example.

On the other hand, the Default branch is for Pull Requests - it identifies

the default branch for merging code into when creating a new Pull Request.

A quick reflection on git reset

Fri, 08 Mar 2019 21:58:00 +0000

This is fairly quick, but I haven't realised how important it is up to now - a friend made up such a mess of his repository adding and changing files before committing that he wanted to delete the folder and start from scratch.

Is it worth it? Not really, you can move around Git's history with this command:

git reset --hard <SHA of the target commit>

Why do I say it is an important thing to keep in mind? Think of it this way: if the user comes from TFVC, this is equivalent to a local Undo All and to Get Specific Version and Get Latest Version (with HEAD instead of the SHA) commands.

Using the Basic Process Template in Azure DevOps to make support management easier

Sun, 17 Feb 2019 15:53:00 +0000

I love the introduction of a Basic Process Template in Azure DevOps, and I will tell you why – it provides a very simple structure for projects that do not want or require a more complex set of prescriptions, but it still feeds from the best practices and the consensus of Agile methodologies so you are not left totally in the dark or to yourself.

An example is support management (as well as escalation management – for the sake of this post I will only refer to support, but many of these concepts apply to both). While there are tools like Service Now which provide an end-to-end lifecycle for support tickets, for certain teams or organisation it can be like hammering a nail for a picture on the wall with a sledgehammer. Doable, but at what cost? Let’s use this scenario as an example.

For starters, you don’t really need Iterations here. While you could use them – nothing wrong with iterations within a support team – you can do equally well without them, it is up to the team and how it is organised. Areas are what you might need: at least an area per product. Don’t be tempted to add many sub-areas under each product, you can easily leverage tags and be way tidier that way.

Also – don’t be scared if you see this error message:

It is perfectly normal, you don’t have bugs in this project! You have Issues instead. So disregard that.

Onto your backlog now, you can start by clicking on the button to create a new Work Item – which is going to be an Issue:

You can go on for a while. I also really like the fact that you can define where the new Work Item goes: top, bottom or at selection. Really neat IMHO.

Once you have a backlog, people start working on it – Azure Boards come in very handy at this, and they are already pre-set in a way that many people will find intuitive:

If you think about it, support management is the perfect example of a Lean project in practice. Stuff comes in, it’s worked on for a while and it comes out on the other side with a status. That’s really it, and the Basic Process Template is a perfect starting point for this kind of approach.

And let me stress that – it is a starting point. You can customise it like any other Process Template and you can change everything about it, but IMHO its real value is in the simplified angle from where it tries to make life simpler for these teams or situations where other structures might be overkill.

The continuous quest for automation in DevOps, and the Azure ML Studio example

Sun, 10 Feb 2019 18:31:00 +0000

When you think about it, most of the tasks you carry on in a DevOps environment revolve around automation.

Infrastructure as Code? It’s automation, right? Cool. Testing? As automated as possible. Integration with 3^rd party systems (SonarQube, WhiteSource, Azure DevOps, Jira, anything you retrieve data from or send data to) – it is automated.

You might think I live in a DevOps bubble. Let’s expand then – SRE? Data processing? How many things we rely on in modern development that have automation to their core? Excellent, you got your answer.

Mind that, it is not a Cloud exclusive. At the end of the day it’s technology we are talking about – hence my mantra “A technology problem is never really a problem. Technology can be bent at will.”

Now, I am working upon a client at the moment which has many efforts going on, and I was asked if I know of a way of automating deployment of Azure Machine Learning Experiments from Azure ML Studio.

Being completely oblivious to the technology I spent some time on it, and despite being a machine learning tool it is quite WYSIWYG. Hence no automation whatsoever, at the moment. Being a cloud-based product there isn’t the shadow of a doubt that eventually it will be implemented (given enough demand, obviously), but it is manual today. And I need to do this today, so there was no other option than going down a custom route.

Let’s pretend for a minute that I am not living under a rock, I don’t know how to use a search engine. The first step here would be to fire up Fiddler and see what happens when you press your buttons in the tool’s UI.

It is a modern web-based tool so there is communication between the UI and some API layer. There will be some sort of authentication involved. You can work your way around it. Eventually, you will be able to replicate this interaction with a script, and put it in your pipeline.

Given I do not live under a rock and I know how to use a browser the first search result would be the excellent Azure ML PS. Using it in a set of PowerShell scripts, stored in a Git repository, to be then consumed by an Azure PowerShell task in Azure DevOps Pipelines is really trivial. Again, this is a valid proposition for both on-premise systems as well as cloud-based systems.

Pipelines are brilliant for this – and I mean it. If you have something ready, or something that cannot use a task, just throw it within a PowerShell or a Bash script and you are in business. Use a Windows agent or a Unix agent, I don’t really care to be fair – as long as you can interact with the target system with a script everything is good in my view.

Sure, there will be situations where automating gets really difficult. Sometimes you can’t avoid doing manual things. Some other times you will be better off rewriting the whole thing. But usually, we are in a quest for continuous automation and it is what keeps us going. Keep automating!

How to reorder your stages in Azure Pipelines

Fri, 01 Feb 2019 16:10:00 +0000

It might seem funny, it might seem stupid... but this might happen to someone else, so it can be handy for the future. How do you re-order your stages in a pipeline?

Let's take this example:

Now, if you want to move Stage 2 to the end, you will try and click on the Stage UI or in the Tasks and you will not find how this is possible.

The answer is in the Pre-deployment conditions:

There you can find the triggers that can be linked to a Stage, which in this case is the completion of a previous stage:

Changing that value will make your re-ordering needs a reality 😊

My road to an open source project: Azure Traffic Manager extension for Azure DevOps

Wed, 23 Jan 2019 15:06:00 +0000

As I mentioned in my last few posts, I have been working in my spare time to convert the existing scripts I had for Azure Traffic Manager into an Azure DevOps extension.

I finally managed a critical point to publish the code on GitHub! I am not a massive code person, it might feel like a drop in the ocean but it is something really big for me :-) It was also a great exercise on the actual end to end process of creating a working extension, which I found extremely interesting and valuable.

The extension does four things at the moment: enable and disable an Endpoint, promote and demote a priority-based Endpoint. It is fairly simple, but again this code stems from demos, labs and community efforts I did over the last 12 months so it is not something that was used by a company in production.

It is available in Public Preview here, and I am still ironing out a few issues both on the pipeline side and the code. Still, given the lack of an official Azure Traffic Manager extension I feel it can be a decent stopgap - at least with these basic features. I will try to make it even more complete over time so it can be even better!

The dev.azure.com URL - can I move away from the old visualstudio.com URL?

Thu, 17 Jan 2019 17:49:00 +0000

Plenty of reasons behind this, but you might want to move away from your <organisation>.visualstudio.com URL and onto the new dev.azure.com/<organisation> URL as a matter of standards.

It is fairly easy to do - straight from the Overview Settings page of the organisation:

If you configured your Build Agents on-premise with a PAT and the old URL you are covered, the configuration will still work, plan for this in advance anyway and make sure you are prepared 👀

The importance of the .gitignore file

Fri, 11 Jan 2019 12:46:00 +0000

A few days ago I spent a some time reviewing some old repositories of mine (mostly demos) and I realised how cluttered they were.

You know why? Because they were created years ago, went unmaintained for ages and they were lacking a .gitignore file.

Early in the days of learning Git, one of the things I left behind was - guess what - a proper usage of .gitignore files. Moving on I realised how important they are: they prevent your repository from becoming filled with temporary files you don't really need. If you go back to old repos you created when you were not as proficient as you are today, you are guaranteed to stumble into that like I did.

For example: if you create an empty MVP Application using ASP.NET Core and you run a git add --all you will surely add files like sqlite's db.lock file, which is utterly useless in a Version Control System.

Or the whole .vs folder, .suo files, the obj folders and so on...you don't need this stuff in a Git repository!

At the end of the day a .gitignore file is literally a list of files to ignore in order to maintain your repository lean and nimble. Spend five minutes (tops!) on it, and you will get the rewards way down the line.

If you are *that* lazy and you think you can't spend five minutes on it, there is a nice service (what isn't commoditised today?!) called gitignore.io that will create a default one for you based off your favourite IDE or environment.

Really, do it! 😁

Recycle your PowerShell scripts in a custom Azure DevOps task

Fri, 28 Dec 2018 11:28:00 +0000

I am a huge PowerShell fan, and pretty much anybody who knows me is aware of that.

Over time I developed my set of scripts for demos and conferences, and some of them are in use in my homelab on a regular basis. One of them is for managing Azure Traffic Manager, and I realised that there is no Azure DevOps task for managing Traffic Manager on the marketplace! Thanks to the brilliant session Utkarsh did at the London Microsoft DevOps Meetup I decided to give a go at at converting that script.

So this is what I did to recycle my script in a task - beware: this post is a crash course on how to do that, and I don't think it is actually anything special. It is just an easy way of productively recycle some existing scripts in a good way. I haven't finished yet - as a good Product Owner I started with an MVP and I see there is more and more to add to it 👀 - but it is slowly coming together and I hope it can be useful to someone in the near future.

What you need to do is create the scaffolding with the tfx cli. from which you can start customising the script.

Then remove any reference to the JavaScript portion of the task - you are just recycling a PowerShell script so you don't need it! It will also save you time when debugging it as otherwise the runner defaults to the JavaScript entry-point. Needless to say, the name of the target script is going to be the name of your script.

Add the VstsTaskSdk module otherwise you are going to get odd errors out. Also, remove any versioning reference. The structure should be .../ps_modules/VstsTaskSdk. This is true for every module you are going to use:

Code-wise, keep the scaffolding as clean as you can, and add your script inside the try statement after the Trace-VstsEnteringInvocation $MyInvocation. You should be able to recycle your script with little changes, of course some adjustment might be needed. If you need to get input parameters you can use the Get-VstsInput command.

How to authenticate with the Azure subscription you select in a custom PowerShell Azure DevOps task

Wed, 19 Dec 2018 08:42:00 +0000

I will cover more about my custom PowerShell Azure DevOps task, but I wanted to share this quick tip as I struggled as much as the next guy about it...

Say that you want to re-use your PowerShell scripts, and instead of having inline PowerShell tasks you want to package them properly for cross-organisational re-use. It is a relatively easy and straightforward task, but chances are you are going to target an Azure subscription with it and you want to have the nice dropbox and the integrated experience you get with first party tasks.

It is not really difficult, but for some reasons I could not really find an easy walkthrough about that - a limited set of steps, but somehow hard to find...

What you need to do is to import the VstsAzureHelpers module and include it in the PowerShell modules consumed by your task. Once that is done, you need to make sure you can select the Azure Subscription in the parameters - easy to do as you need to edit the task.json file:

After this you can finally use the Initialize-Azure command in your PowerShell script, which is going to automatically pick the subscription from the parameter and initialise the relevant cmdlets so that you can use stuff like Set-AzureRM... without running Login-AzureRmAccount.

Easier done than said 😀 I hope it is going to be helpful!

Lift and shift migration of Team Foundation Server to Azure with Azure DevOps Server 2019

Thu, 06 Dec 2018 19:58:00 +0000

This is a consequence of the support for Azure SQL Database - as you can use it as a data tier now, you can also upgrade your existing Team Foundation Server instance to Azure DevOps in a lift and shift fashion.

First of all -- *this works on my machine* (lab) and *I bear no responsibilities* 😁 it is highly experimental and only with Azure DevOps Server 2019 RC1 - although I am sure it is going to be polished in the next releases. Let's review the pre-requisites:

You need to run domain-joined VM(s)
The(se) VM(s) must have a Managed Identity in order to access Azure SQL Database

In order to lift and shift your databases, you need to import them into Azure SQL Database. You can use many methods like the Microsoft Data Migration Assistant, SSMS or a manual import.

It is likely that you need to remove all the Windows users, and the table and stored procedures used for the scheduled backups. Remember that as of now it is still an experimental process - no support whatsoever for this, especially because you are modifying the database manually!

Once the database are imported (S3 tier or above!) you need to run this query on the Azure DevOps databases:

CREATE USER <vmname> FROM EXTERNAL PROVIDER

ALTER ROLE db_owner ADD MEMBER <vmname>

ALTER USER <vmname> WITH DEFAULT_SCHEMA=dbo

Followed by this query in the master database:

CREATE USER <vmname> FROM EXTERNAL PROVIDER

ALTER ROLE dbmanager ADD MEMBER <vmname>

This is it really - then you can launch your Azure DevOps Server Configuration Wizard and proceed to an upgrade. Yes, even if you already installed Azure DevOps Server! Of course there are changes to perform here, so it makes sense to call it as such:

Time for a change

Fri, 30 Nov 2018 08:44:00 +0000

Today is my last day at Quest Software and One Identity. Moving on has been a hard-thought decision, after over five and a half years. I met some great people there, and I managed to grow a lot given the different perspective I found myself in after day one.
Working with Vladimir Gusarov was thoroughly great, we've gone through a lot of scenarios and situations but we always managed to get positives out of them.

It is never easy to move on - so many memories and experiences to carry on with you. The company deserves a huge 'thank you!' for this ride, and I can only speak well about them. Thanks!

Now, where am I moving to? Well... I could tease you, but it would be kinda pointless 😊 I am moving back to Avanade, but in the UK branch.

This means I am going to work with a somewhat known group of people - Tarun Arora, Vlatko Ivanovski and Utkarsh Shigihalli for starters. But I will also manage to catch up with people I worked with when six years ago... maybe I should start rehearsing my best version of Terminator's "I am back" 😂

Big changes in Azure DevOps Server 2019 - Inherited Processes

Mon, 26 Nov 2018 12:18:00 +0000

Another huge feature brought by Azure DevOps Server 2019 is Process Inheritance - meaning you are going to get the same customisation experience you get today on Azure DevOps Services on your own Azure DevOps Server instance.

It is a collection-wide setting and it cannot be changed once the collection is created, so you won't get it for free when you upgrade to the new version of the product. But there are ways of moving stuff across, and if you do you will get all the benefits from the new model.

Why am I so excited about it? Because as of now, the on-premise customisation was very powerful but also quite complex to master. The Process Template Editor in Visual Studio, witadmin.exe, storing the versioned changes somewhere else, all things that require time and effort, especially when you need to manage an instance that provide a service to your users.

With the new process model customisations can be implemented straight from the Web UI, and finally the concept of process inheritance comes on-premise, making your life much easier.

Once you start using this different approach you will be able to easily apply derived processes to your projects, without going through all the existing fiddling with witadmin or the Process Editor. It is a massive improvement.

Big changes in Azure DevOps Server 2019 - SQL Azure Database support

Wed, 21 Nov 2018 18:39:00 +0000

This is the first of a (hopefully!) series of posts looking at the substantial new features of Azure DevOps Server, which was released yesterday in RC1.

If you follow my blog you know that despite everything going on around Azure DevOps Services, I have a soft spot for Azure DevOps Server (formerly Team Foundation Server) - the on-premise product.

Why? Well, since it is a quarterly snapshot of the code from the service it seems excellent value in terms of what it offers once brought on-premise!

This is quite an important feature I reckon: Azure DevOps Server now supports Azure SQL Database as the Data Tier.

I can already see you are scratching your head, a little puzzled. Let's put some red lines here, shall we? This configuration works (not "is supported" - works!) only when you are running an Azure DevOps Server instance in an Azure VM. So this is already a huge restriction, but it makes sense - you cannot have better connectivity than something already within the Azure datacentre. After all, on-premise does not necessarily need to be inside a wholly-owned datacentre.

Also, when you create the Application Tier VM(s) you need to assign a System assigned Managed Identity to it - this is how the VM will authenticate with your database, and this is what will enable the Azure option in the deployment screen you saw before.

Also, you need to provision at least two empty databases in advance: the Configuration database (name it Tfs_Configuration, for now) and the main Collection database (again, Tfs_DefaultCollection?). Once you have these two up and running, you need to set an AAD administrator user and assign these roles to your databases:

AT here is the name of the VM, as you are leveraging on the system assigned managed identity. AAD is required to actually manipulate the databases. Also, the first SQL script needs to run only against the master database, while the second one should run against the Configuration database and the Collection database.

What if you don't run these? The wizard put a series of checks in place to prevent a botched configuration. Hence, if you don't run the first script you are not allowing the VM to authenticate against the Azure SQL Database Server, causing this error:

Without the second script you will get an explicit error during the Readiness Checks. Eventually, all databases should run an S3 tier or above, otherwise you will be prevented to configure the instance (for the Configuration database) or you will get various errors and your collection will not be provisioned.

Why all of this? Put yourself in the shoes of someone who deals with a 3TB Collection on a daily basis. Backups, storage, DBCC, hardware performance and high availability. Can you see the reasons why? 😀

Tips on granular migrations with the Migration Tools for Azure DevOps

Tue, 13 Nov 2018 17:24:00 +0000

As you know, I am a huge fan of Martin Hinshelwood's Migration Tools for Azure DevOps. I've been using them for the past few months, and I put together a list of common occurrences that you are likely to face.

Throttling - it is going to happen!

You cannot do anything about it - you are hitting a cloud service, so it is inevitable that you are going to get throttled because of the irregular shape and the amount of data you are moving. What I can tell you is that if you are migrating an average amount of Work Items (in the low thousands I reckon) you are very likely to hit throttling using the LinkMigrationContext processor because of the load generated on the service.

Correct use of the ReflectedWorkItemID field

I experimented a fair bit with it, and the solution is to actually have it on both ends for the best outcome. Also remember that custom fields in Azure DevOps Services are unique, so don't be tempted to create the ReflectedWorkItemID field in the custom project used by only a project while you will need to re-use it across the board.

Always create a custom process first - to be used as a starting point for migrated projects that is going to have that field - and then apply that to the target project with whatever further customisation you need.

Split your migrations into core and non-core processors

When do you need your users to be away from the source system? When can they start using the target system? All questions that are going to pop around, sooner rather than later.

In my opinion if you are performing a Work Item migration they can start working after Areas/Iterations, Work Items and relationship links have been migrated. Why? Because unless you have someone who is really into his/her attachments, that is the main staple of the Work Item Tracking pillar of Azure DevOps.

Every project is different, of course. But these are my notes so they are skewed from my personal experience 😊

Identify what needs to be migrated right now and what can wait

If you have too much data to move and you cannot afford that downtime, you need to change your scope. A feasible approach is to move what is currently active, meaning people can start working right away. Once that is done, you can start batching all the closed items - remember that the WorkItemMigrationContext uses WIQL behind the scenes to identify what is going to be moved, so it is very straightforward.

Doing this makes sure that everything will eventually be migrated, but without the time pressure of the usage downtime. It is just down to coordination.

Why you should scan your code within your pipelines

Sun, 28 Oct 2018 17:15:00 +0000

Like many I received this email from GitHub a couple of weeks ago on an old repository:

This made me think about how important security scanning is in this day and age. Your code might have been top notch a couple of years ago, and being dangerous today.

So, to have a bit of a laugh, I hooked up WhiteSource Bolt to a build of that code to see the actual outcome on the open source libraries used there.

WhiteSource Bolt is also free for Azure DevOps, so there is really little stopping you from scanning your code 😊this is the (kind of expected result):

This is code from a couple of years ago – do you think your code from two years ago is still as good as it was back then? 😊

Unblock the SonarQube upgrade process when using Azure AD plugin for authentication

Mon, 22 Oct 2018 15:25:00 +0000

There is a well known issue with SonarQube's Azure AD plugin, where an upgrade from v6.x to v7.x fails. Fixing this issue involves modifying the Users table manually outside of the upgrade process, and at the moment it is something you cannot avoid.

The reason why this happens is because the external_identity column does not contain a unique value, while instead it is filled with 'Azure AD' for each user. This is not a critical column, and you should be able to do this without issues.

Then I thought about a handy way of fixing this instead of just writing random data in it. Whenever you sign-in with the new plug-in, 'Azure AD' is going to be replaced with your email. So, I put together this very simple script.

Before you run this remember that I bear no responsibilities from it - it worked on my machine, it might not on yours 😊 always test it on backups first!

This takes care of the uniqueness of the value and enables the upgrade to go ahead. Needless to say that this script can be easily added to my proof-of-concept of automated pipeline!

A small detail to keep in mind while exporting Build Definitions

Fri, 12 Oct 2018 09:09:00 +0000

As part of a migration process you might want to easily migrate the Build Definitions for your pipelines – you can easily do this by using the Export Definition in your Pipelines:

This will create a .json file you can import in your destination project with all the properties of your build pipeline, but bear in mind that there is no magic going on here: if you import it in a different Team Project, it is not going to automatically re-target your definitions, hence you would be pointing at the old repository and the old branch.

It can be quite worrisome if you are moving stuff across Team Projects while keeping them available – there will be no warning, meaning you will get odd errors like this. You’ve been warned 😊

Why Universal Packages?

Tue, 09 Oct 2018 09:47:00 +0000

You might have read about the new Universal Package, something I am quite a fan of. There is no need for a huge software system in order to use them: actually I read about the many situations where they come in handy, but I believe I have a great one-size-fits-all example.

We know that Git, a file-system based Version Control System, is not suited for binary storage. The solution I always recommended was to use a TFVC (yes! TFVC!) repository so that you will not only get transactional consistency when consuming these files, but also versioning.

At the end of the day, these files would be stored in a database hence TFVC fits the bill quite well. But it was kind of a basic solution for this scenario, as it does not offer what Universal Packages do. The whole idea is to create packages to be easily consumed by other users, not fiddle with yet another Version Control System.

Universal Packages not only do this, but they also offer a great deal of compression. Something that is really welcome when it comes to binary files.

My example exactly: let’s say you store media files for your products. Images, videos, stuff that is not textual. You need to consume these files during your pipeline’s execution, in whatever scenario you need them.

Compression (in terms of package size) means performance when consuming them, something that is extremely welcome IMHO. And as you can version packages, you get versioning as well. All by using something that is optimised for that scenario, instead of bending some other sort of technology.

Should I use GitHub to use the ten free Azure Pipelines?

Tue, 25 Sep 2018 15:05:00 +0000

At yesterday's meetup we got this question: why should I use GitHub to get the ten free parallel Azure Pipelines if I already have a project in the service?

It is an excellent question, and the answer is that you should use GitHub only if you want to. As long as a project is marked as Public in Azure DevOps it will get the ten free pipelines!

You can verify it yourself: mark a project as Public:

Now browse to the Retention and parallel jobs section of the Build and Release settings menu, and check it yourself under the Parallel Jobs tab - 10 jobs!

Having free Pipelines is not about being forced to use GitHub, it just means you get them as long as your project is public - regardless of the location.

Use the free Azure Pipeline plan with your GitHub project!

Sun, 23 Sep 2018 17:27:00 +0000

It's been a couple of weeks from the Azure DevOps announcement, and I am contemplating an amazing London sunset while I prepare for tomorrow's event.

Before getting distracted by the landscape, I was setting up the free Azure Pipelines offer with a GitHub repository of mine... and I realised how frictionless it is!

Start from here and select the Free plan:

Then select if you want to apply that plan to all your repositories or if you want to use it for select ones:

Now, either select an existing organisation or create a new one, and use a project (in my case a new one called GitHub, but you can use an existing one a well) to refer to the GitHub project. I say refer because the level of interaction with Azure DevOps is kept to a minimum - you are consuming it, but you are not doing anything else with it as of now:

Once you are done, select the template you feel it is closer to your project. In my case I selected a .NET Desktop template because I am building legacy code so it would be the most appropriate:

This will create a yml definition in your repository. Save it, and trigger it - job done!

This was for something I had there since I barely remember when...hence it should not be too difficult to set up Pipelines for your project! 😊

The build is already set up to perform CI and PR validation, so there is little effort other than create it and potentially customise it.

And it is not a joke when we mention the ten parallel free pipelines - they are already there, provisioned for your account!

So... what happened to VSTS?

Mon, 17 Sep 2018 10:35:00 +0000

Yes I know – it is a bit of an old news, but I was on holiday and I realised that there are so many crumbs of information around, hence a nice summarising post would help.

On 10^th September, Visual Studio Team Services became Azure DevOps. First things first: does this mean that now you cannot target on-premise, AWS or GCP? You couldn’t be more wrong – there is no change on that front. You are free to use any technology and to target any environment with it, it just happens to fall under the Azure umbrella.

I personally feel that the new name, despite being a huge change, underlines the fact that the stack is a business driver, not just a development tool. If you are an existing ~~VSTS~~ Azure DevOps user, what changes for you is how the product is packaged – if you had to get all of the ~~VSTS~~ Azure DevOps services before, now you can choose what to actually get: Boards, Pipelines, Repos, etc.

So you will get a nice per-project selector:

This means that if you want to use an Azure DevOps project just for the Work Item Tracking features and completely hide the Repos, you can totally do that.

Also, the whole UX changed. For the better, I reckon – I find it much improved in pretty much all areas, it just feels better to use. The URL formatting changed (from <org>.visualstudio.comto dev.azure.com/<org>), but it won’t break anything – Microsoft is well aware of this, and it is not going to touch the URLs for the foreseeable future.

Then, the elephant in the room – the open-source offering for Azure Pipelines. When I first heard about it, I had to double check I was not making a mistake. Ten free parallel jobs (effectively it is like having ten build machines) with unlimited minutes for OSS projects, regardless of what technologies you use. The agents run on Windows, Linux and MacOS, making it really cross-platform and open to everyone.

Put aside technology for a moment, and think about it. Ten parallel builds with unlimited minutes, for free. It would a relevant cost that is completely slashed away, making end-to-end OSS delivery as easy as drinking a cup of coffee. I believe it is quite unprecedented, and kudos to Microsoft for offering this.

Eventually, Team Foundation Server is going to be renamed to Azure DevOps Server from the next major release. No other changes on that front, it is still a regular snapshot of Azure DevOps brought on-premise. And no, I don't think it is going to be discontinued anytime soon!

That’s it in a nutshell. It’s a large revamp, but the underlying pillars are still there. Enjoy it!

A collection of SQL Server-related tips for the TFS Administrator

Mon, 20 Aug 2018 19:56:00 +0000

If you run Team Foundation Server on-premise, understanding how SQL Server works on the Data Tier is extremely important. Despite the push for the cloud, there might be so many reasons why you need to stick with your on-premise installation of TFS – and the bigger the instance is the more SQL Server knowledge you will eventually need.

I am not a SQL Server expert myself, but between my past as a consultant and now being in a position where I administer a huge TFS instance meant that sooner or later I had to deal with SQL Server on a one-to-one basis. Not always the happiest of encounters to be fair 😊 but still, I learned a lot. So I thought that if you are in my position – where you might be the TFS Administrator – then hopefully a collection of notes I took over time might be handy for you.

SQL Server always wins – be prepared for it – and never, ever touch the databases

It’s not really a tip, but something to keep in mind: given that Team Foundation Server is essentially a product where you have web services in front of a set of databases, hence if the databases have problems the whole product is down. Remember that – when something goes (very) wrong, keep in mind the Data Tier, sometimes it is silly stuff like the drive where the master database resides being full…

Also, never, ever touch the databases manually unless instructed by the Microsoft Support Team. Don’t be tempted to optimise the databases, the number of things that can go wrong is simply too high to risk being in a corrupted state or unsupported situation. Don’t do that.

Use the TFS Administration Console built-in backup tool if you can

The temptation of letting someone else (the IT department, a DBA, etc.) deal with the menial task of backing up your Data Tier can be very high, but if you can just use the built-in backup tool. It makes it transparent to you and takes away the hassle of creating maintenance plans.

If you have databases in Full Recovery Mode, it will take care of your Transaction Logs backup in an atomic manner – it is very important. If you take backups at different times for example, you might end up in a situation where you have identities in a Collection database which does not correlate with the Configuration database. To avoid this, you should mark your transactions as part of your backup plan.

Also don’t forget to backup your SSRS Encryption Key, otherwise you might be restoring a useless set of databases in a Disaster Recovery scenario!

High Availability means AlwaysOn!

To be fair it is not really the case, but it makes your life so much simpler. AlwaysOn makes Highly Available deployments a breeze, and even if you have to factor in some adjustments to your habits it is worth it every single time.

Beware though: even if you implement AlwaysOn for your Database Engine, you will not get Analysis Services for free on the same setup – that is a different deployment altogether.

Keep an eye on your drives

This is something I experienced fairly recently – aside from the usual recommendation on where to put your databases (system or otherwise), if you have a very large database you could run into file system limitations that prevent DBCC CHECKDB from running and make you lose sleep. If you happen to experience these, it is worth knowing that not everything is lost and you might not even need to restore from a backup.

NTFS has a switch (/L) that is designed around large files, it is an excellent starting point although you need to format your drives. Another solution revolves around using ReFS instead of NTFS – it is something somehow unknown, but after running it for a while in my homelab and using it to solve a portion of this problem I can say that ReFS is a powerful “tool” (I can’t really consider a file system a tool, but for lack of a better word…) to resort to in case you find the dreaded error 665 in your logs.

Remember to check what is going on

I use this couple of queries since… I don’t know, ages. They help, because they show in a transparent way what is going on within a SQL Server instance (especially if you need to understand what AlwaysOn is doing) and they provide information that can help diagnosing certain errors.

How VSTS Sync Migrator is going to change then way you migrate to VSTS

Thu, 09 Aug 2018 21:12:00 +0000

Like I said in my last post, I really enjoy using VSTS Sync Migrator for Work Item migrations.
There are a few reasons why I believe this tool stands out from the rest, and it is not just because of its complexity - in a nutshell, you can use it not just for tip migrations, but to actually filter and sanitise what you are importing into your target TFS or VSTS.

Firstly, you can run each processor (call them steps if you want) independently. That is very important when it comes to understanding what each one of them does. You don't really want to use something that starts, does stuff and then fails with an enormous log file.

Each processor is extremely specialised and usually backed by a WIQL - again, quite complex sometimes but extremely powerful and flexible.

You can also run multiple instances of the Migrator, targeting different Team Projects in VSTS - having them side by side isn't usually a problem.

Then, you have a really powerful capability for shaping your data in the best possible way. By "shaping" I mean "mapping": field to field, replacing values, even replacing values via Regular Expressions or mapping different Work Item Types.

This can enable all sorts of scenarios where you can change a Process Template, or make your very verbose customised form much more readable by merging or moving around fields' data.

Eventually, no ancillary item is left behind, including Work Item Queries (which carry a huge business value IMHO) and commit information. You can link commits to Work Items even if you migrated the repository with a different name.

It takes a while to get all the bits right - there are lots of options, but the documentation is quite good and it will easily guide you through. Fellow MVP Mohamed Radwan also recorded a quick demo of how to use it.

Now, onto more VSTS migrations 😀

A set of tools to deal with granular VSTS migrations

Tue, 31 Jul 2018 16:11:00 +0000

I am in the middle of a TFS to VSTS migration, and unfortunately I cannot use the TFS Database Import Service this time around. So I put together this list of tools to use for a granular migration, together with scenarios.

It is going to be mostly on the Work Item side to be fair - if you want to move code quickly look at the last post.

TFS Integration Platform

Yes, I start from the oldest of the bunch. While unsupported and fairly old, the Integration Platform still works decently given the chance.

There are lots of limitations though: you are limited to the Client OM, and you need some tricks to make it work, like creating fake registry entry to make it believe you actually have Team Explorer 2012 (unless you install it, of course).

I reckon the Integration Platform these days works well with a limited scope migration. The pain here is that everything needs to be sorted manually and it gets sluggish after a while, for some reason.

TfsCmdlets

Say that you want to quickly work with Areas and Iterations, or that you want to script them. This is an example where the TfsCmdlets are extremely powerful.

In my case, I am using them extensively to prepare empty target Team Projects. It is basic PowerShell, hence you can manipulate your objects as you like and they make your life extremely easy.

You don't migrate stuff with the TfsCmdlets, but it is a really invaluable tool for all the ancillary items around the migration itself.

VSTS Work Item Migrator

The Work Item Migrator is an open source project from Microsoft that leverages the REST API layer of TFS and VSTS.

It is more of a sample of how to deal with the APIs IMHO, but it is an excellent starting point. It is based off a Work Item Query as a source, which means you can easily scope what you want. Areas and Iterations need to be created beforehand.

One note here: if the validation succeeds, it is not guaranteed that the tool will migrate everything, but that depends on many factors.

VSTS Sync Migrator

Martin Hinshelwood's VSTS Sync Migrator is a real powerhouse - it is quite complex and it has lots of features (including reconnecting commits to Work Items), it can take a little while to refine the result but it is great.

You can also do remaps with this tool, so you can easily migrate from one Process Template to another. It is easy to do because you will configure it yourself in the configuration file. What I really like about this tool is that I can have a very complex configuration but keep some of the steps in a disabled state - so I can have a nice incremental experience.

I want to move my project from TFVC on TFS to Git on VSTS, without command-line tools. Can I do it?

Tue, 17 Jul 2018 10:08:00 +0000

Many often do not realise how easy is to consume technology to make it accomplish a certain scenario. This happened just last week to me.

For example: you have a project on a Team Foundation Server, which uses TFVC. TFS is only available via the corporate LAN, while you want to move it to the new company’s VSTS account and you also want to move to Git. Throwing an extra spanner in the works, you want something easy to use which does not require any kind of command-line use.

Does it sound too complicated? It is actually a matter of a couple of clicks.

The first step is to use the Import Repository feature on your local TFS – what you will do is to convert a branch from TFVC ($/MyProject/mainfor example) to a new Git repository:

You can retain as much as 180 days of history, which is more than enough IMHO. If you need more, you can keep the old system around and look it out there. Why? Because of how TFVC and Git differ – it would not really make sense, and you are just adding stuff to a repository that should be as nimble as possible. Also, you are limited to 1GB per imported branch.

Once you are happy with it you can add your VSTS target repository as a remote, and push it there. Job done.

Review – Accelerate

Tue, 10 Jul 2018 11:00:00 +0000

As you know, I am not only a technology enthusiast but also very into the business side of DevOps. And as a fan of The Phoenix Project, I really could not refrain from purchasing it 😊

Also, the focus is on High Performing Technology Organisations (HPTO from now on), which is a very broad subject intertwining technology, management, strategy. Enough to keep me interested.

I read it twice before writing this review. Yes, twice. And the conclusion is very simple: it carries a huge horizontal value. This book is not the typical technical or business book, its approach is more scientific, almost academic.

A real HPTO is a well-oiled machine that requires lots of work all across the board. And that is where it shines for business value: despite this approach, the result is that each chapter can be picked by any company as a project on its own to improve itself and go towards the required maturity to ‘be’ an HPTO.

Technical best practices? Chapter four. Infosec and the shift left on security? Chapter six. Employee empowerment through management? Chapter nine. Each chapter has enough stuff to keep you, your teams and your companies busy for months, if you actually start a project on it. And given that I do not think every reader of this book works in a HPTO, you definitely should start some projects 😊

Summarising it in a single sentence, the issue at heart is that software is the actual business engine. That is what the book underlines as well - without a good software factory you simply cannot deliver value to your users, and if you don’t deliver value…

A set of tricky situations with HTTPS and TFS

Wed, 27 Jun 2018 16:53:00 +0000

HTTPS is more and more common-place, not just for public websites but also for internal websites. This is extremely good for a number of reasons, but from an administration standpoint there are a few bits to keep in mind.

In particular, when it comes to Team Foundation Server this is a list of errors and problems that go away with a common denominator: the right certificate.

The number one offender is of course the out-of-domain machine. If you have a domain-joined machines these problems simply do not happen because the internal certificate is deployed by the domain GPO - hence you don't have to fiddle with it. When your machine is not domain-joined, things can easily go south.

Bear in mind - these are not security tips, this is just a collection of situations which you will face if you deploy HTTPS with TFS.

Non domain-joined machines

If you are running a non domain-joined machine then you need to procure the root certificate for your domain and install it in the Trusted Root Certification Authorities store on your machine. This needs to be done on any machine not part of your domain, otherwise you won't be able to do pretty much anything.

Build agents

Build agents need to be reconfigured. You can't run away from this, if you don't do that they will be working until the authentication token expires, and then you will start seeing this error in the Event Log after they go offline:

Agent connect error: The audience of the token is invalid.. Retrying every 30 seconds until reconnected

You need to de-register (config.cmd remove) and re-register your build agents in any pool. Not too bad, but it needs to be planned for.

The Deploy Test Agent task in Build and Release

If you don't have your certificate installed on both the Agent (if outside the domain) and the target machine (again, if outside the domain) then you will get this cryptic error:

The running command stopped because the preference variable "ErrorActionPreference" or common parameter is set to Stop: Exception calling ".ctor" with "2" argument(s): "One or more errors occurred."

It's a communication issue between the target machine and TFS. Once the certificate is installed it goes away and the task works normally. This GitHub issue also recommends enabling TLS v1.2, which is not a bad idea.

Git

Git holds a special spot in this collection, because of how it handles SSL. While newer versions of Git for Windows made this really straightforward (hint: they support the Windows Credential Manager), but if you aren't running the latest and greatest then this is what could happen with Git on your local machine, even if it is joined to the domain:

C:\>git clone https://myserver/Collection/_git/Project
Cloning into 'Project'...
fatal: unable to access 'https://myserver/Collection/_git/Project/': SSL certificate problem: unable to get local issuer certificate

You can sort this out in many ways, but the best one is Philip Kelley's approach. It just works, even if it is a bit of a walkthrough. This applies not only on the client, but also on the build agent if you are not running a recent version of the agent itself. It can be easily corrected by replacing the ca-bundle.crt file over there, it is not going to be replaced until you update the agent to a newer version.

Also, a false friend:

error: RPC failed; curl 56 OpenSSL SSL_read: SSL_ERROR_SYSCALL, errno 10054
fatal: read error: Invalid argument, 255.05 MiB | 1.35 MiB/s
fatal: early EOF
fatal: index-pack failed

It can be all sorts of things, especially as the error points at OpenSSL - but check your connection's stability first before messing up with Git's postBuffer and compression 😃 if the git clone operation starts the problem is not the SSL authentication.

Easily handle internal settings while orchestrating components' deployments and parameters

Wed, 20 Jun 2018 09:24:00 +0000

After ten years of attending, then speaking at conferences it always strikes me what demos often miss are real world details that really make the difference.

Like...deploying an application with a pipeline. Everybody talks about it, right? And everybody (including myself!) have some demo-ready stuff to show around in case it might be required.

I am working on a sample application right now, and I realised how blind I was - even if I am deploying stuff to different slots and environments and whatnot, I am still treating everything as a single monolith. Not really what you want these days, right?

Well' let's sort it out. Say that you have an API component and a Frontend component, the best thing to do is to decouple the two of them so they can be independently deployed *and* mix-matched depending on the requirement.

It is .NET Core in my case, so in my Frontend component's appsettings.json I created this section:

Of course I modified the application so I could add the configuration in my ConfigureServices method and consume it in my Controller. The variable part in this case is the Slot property.

Now comes the fun side of the story - of course I have a pipeline in place. How do I handle these settings?

The best approach here, given the relative complexity of this exercise, is to scope the relevant value by environment. The Dev environment will always point at the Dev environment, Staging to Staging, and the last two environments are effectively production so I do not need to worry about adding a slot. It's not like I have cross-environment settings here.

The reason why the variables are named that way is because I am using the JSON variable substitution option in the Azure App Service Deploy task, and as my property is not on the first level then it needs to be explicitly written that way.

Doing it ensures that each environment has its own setting, and it also makes sure you remain sane while handling internal app settings across your applications and environments 😉 it is really easy to do as well, so there is really no reason to skimp on it.

Quickly deploy a baseline SQL database with VSTS

Sat, 16 Jun 2018 16:53:00 +0000

"Sometimes we go full steam ahead with a complex solution for a very simple problem..."

That was the answer I gave to a friend of mine who asked me how to feed some baseline database for testing purposes with VSTS in Azure.

The obvious one would be to have your versioned SQL scripts in a dedicated repository which you can use to rebuild the whole thing from code (which is by all accounts the most correct solution to this problem). But in this case there are other avenues.

Databases have been treated like second class citizens for years - by tools and practices. For example, why not using BACPAC files for this exercise? At the end of the day, a BACPAC file contains the packaged version of a database at a certain point in time, including its data.

So if you have your BACPAC somewhere, get to an Azure storage account and run this SQLPackage command inside a VSTS PowerShell Script task (of course you need to replace the variables and provide the actual path):

& 'C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\Extensions\Microsoft\SQLDB\DAC\130\sqlpackage.exe' /Action:Import /TargetServerName:$(DBUrl) /TargetDatabaseName:$(DBName) /TargetUser:$(DBAdmin) /TargetPassword:$(DBPassword) /SourceFile:"<your location>/sample.bacpac"

Don't get me wrong, I love seeing a database fully integrated with the pipeline and that's how it should be. But in this specific case, I feel the tradeoff is worth it.

Also - this is a baseline database, nobody prevents us from running delta scripts against it depending on needs. But given it was for testing purposes, I highly doubt there is going to be much development on it in the future!

How to run UI tests in a Deployment Group with TFS and VSTS

Thu, 07 Jun 2018 10:45:00 +0000

Especially if you are testing client applications, you might want to run UI tests on a Deployment Group instead of a Build Agent. While technology is the same, there are a couple of things to keep in mind.

In order to enable a machine to run UI tests you need to make sure your InteractiveSession capability is set to true.

In order to do so, you need to re-configure or manually change the script used to add a machine to the Deployment Group. Given a standard script the first step is removing the --runasservice switch from it.

Once you run the configuration script the process will guide you to configure the agent for interactive interaction. You will set it to auto-start so you will get an unattended experience when rebooting the machine, but you will be able to run interactive sessions on it.

Eventually, I always recommend to use the VSTest Platform Installer task to make sure you have a consistent environment to run your tests from:

and to refer to the tools installed by that in the Visual Studio Test task:

A story of high availability with SQL Server AlwaysOn and TFS

Wed, 30 May 2018 11:20:00 +0000

A few weeks ago something happened on our TFS instance - we discovered that DBCC CHECKDB under certain conditions can mark a database as corrupted.

Long story short, this was due to a peculiar condition related to a high volume of transactions during that operation, not something you see every day. Microsoft Support was really good helping us getting back to normality.

In retrospective, what really hit me was how resilient TFS was thanks to SQL Server AlwaysOn. As you know, I am a huge fan of AlwaysOn because of how transparent it makes High Availability.

For us, maintaining availability meant a simple failover to the other node. Given that we are running the Availability Group with Synchronous-Commit Mode (my default choice when it comes to TFS) the then-Primary Replica was already updated to the latest transaction, so there was no data loss.

Team Foundation Server did not lose a single heartbeat. When things go south like this, during the issue itself and if you are doing something during the failover you will get a JobInitializationError, which is self-explanative. As this is a transactional system by design, nothing is left hanging in the balance like good ol' SourceSafe :)

Of course we were in limited availability while we were troubleshooting and fixing this problem (always change the Failover Mode to Manual when you are doing so), but there was no downtime.

Also talking recovery, at the end of the day we had to restore backups on the Secondary Replica to get back to a proper synchronisation. Again, a bit tedious and time consuming given the sizes involved, but it was flawless.

Small details carrying a huge value

Tue, 22 May 2018 15:16:00 +0000

I was reading this post by Microsoft Premier Developer’s blog, and it was a nice throwback to past times where I had to deal with these type of requests because of the existing process in place.

I also thought about how easy it became customising a process with VSTS compared to TFS, and the first thing that sprung to mind was to pair this up with the Board Styling options:

This will cause cards that are unassigned to a single individual but assigned to a group to be highlighted in the board:

There can be so may reasons why a team might choose to do this – and it does not just apply to product development. Think about situations where telemetry operators escalate events or tickets are integrated in the backlog.

Why am I focusing on such small details? Well, this is the kind of personalisation (I cannot really call them customisations 😊) that enable cross-role consumption of the stack.

It does not have to be anything extremely complicated, but whenever you can bring an existing process inside the tool in a frictionless manner you are already paving the way for a better reception and adoption of the tool itself.

Elevate your telemetry from silo to valuable data source

Fri, 11 May 2018 07:23:00 +0000

I am going to speak at DevOpsDays Kiel next week about telemetry, and I was thinking about how much Application Insights evolved in the last few years.

Without mentioning the awesome Application Insights Analytics, I was really pleased with how easy it is to bring valuable data to the forefront.

For example, this was there pretty much since the inception:

It’s great, but it is kind-of-buried in the detailed information provided. What I really enjoyed on the other hand, was this:

This is an organic and straightforward way to escalate a single piece of information. Why you ask?

Well, because the previous screen is a summary, with a single button named Operations in a pane called Take Action.

So, from a UX point of view, it comes natural to dig into the details of a single request raising an exception and promote that information to an actionable backlog item.

A development team does not (usually) need quantity, it needs quality in order to fix problems raised by telemetry. It is the natural evolution of telemetry systems to be able to integrate with DevOps stacks in an effortless way – the real challenge is doing so without being excessively verbose, but still providing the much needed value to close the loop.

Review – Professional Visual Studio 2017

Mon, 30 Apr 2018 13:33:00 +0000

I recently gave a go to this book, because I feel it is important as a stepping stone to whoever is approaching the IDE – remember, there is always somebody who is starting around 😊

It does its job well to be fair, it covers pretty well all the features and it is pretty up-to-date with the RTM release of the IDE. The only problem I find with it is that the Visual Studio release cadence is going pretty fast, so it will always be a matter of playing catch-up with the team. There is so much that is added and updated on a regular basis that it is almost inevitable for a book like this to fall behind.

Regardless of that, there is also a nice introduction to the Continuous Delivery Tools for Visual Studio that happens to be a nice starting point to the DevOps and CD pipelines tools as well – including Code Analysis.

Visual Studio Team Services is mentioned at the end, instead of Team Foundation Server. It is a change that makes sense, as it is extremely quick and easy to get started there instead of installing TFS.

On-premise Blue-Green deployments with TFS 2018 Update 2

Wed, 11 Apr 2018 16:13:00 +0000

Like I said in the previous post, modern deployment patterns are not an exclusive of the OTT providers and they are not something that requires using cloud technologies.

After Rolling Deployments, another very common pattern you might want to tackle is Blue-Green deployments. In a nutshell, it means having two identical environments to use in order to deploy new versions of your application with minimal downtime.

It is a bit harder compared to a Rolling Deployment – mainly because there could be countless variations on the technical details, depending on how your environment is composed, but let’s try to jot down a skeleton version of a Blue-Green pipeline you can use.

So in my case, I am using the same application I used in the previous post, with an additional environment (which happen to be a cluster, just to keep things a little more realistic). This is what my pipeline looks like:

Each environments follows the following process:

Let’s say we are running all of this against the blue cluster, which is currently production.

The first phase is an Agent Phase – it swaps production traffic from the blue cluster to the green one.

I want it to be independent from the environments so that it can deal with the router that manages traffic between the two clusters. As I do not have an appliance or anything special in front of them (I am just playing with CNAME records in my lab domain) this ensures the process is not tied to any machine.

Moreover, this pipeline is designed to be used just after everything is deemed production-ready, so if it fails it is not meant to be ran again without a hitch.

The reason behind this choice is that I wanted to share a general idea of how to do this on-premise, and there might be so many permutations of what you might need to do or what could go wrong that my example with all the possible fail safes in place would have been way too complex.

Up next, the Rolling Deployment we saw in the last post for both nodes of the blue cluster, one at a time.

Then, even if you are running this for a production application you still need to make sure your smoke tests are passing. This is literally the last line of defense before the switch.

Eventually, a warm-up script to ensure that my application is responding correctly when it is going to be used from my users.

Now the magic happens: as soon as you move to the second Environment, traffic is switched to the blue cluster again (which is done with the v2, and warm enough for production traffic) in a seamless way while the whole process goes on against the green cluster.

Of course, there are some things to consider. The first one, is that this pipeline is not designed to be a commit-to-production pipeline: there is no backup mechanism in it and no revert process if one environment fails (this lives with the fact that you should already have the pipelines defined in the previous post though 😊).

You want to use approvals to manage the switch from green to blue, so that only when it is checked then you can go ahead.

Eventually (this is quite important though), your application must be able to cope with environment change – it should be message-based, or stateless. Traditional stateful applications can have problems with it, which can be mitigated with message queues for example, so we are back to square one 😊

On-premise rolling deployments with TFS 2018 Update 2

Wed, 04 Apr 2018 13:40:00 +0000

Team Foundation Server delivers– as usual – the periodic snapshot of VSTS goodness on-premise.

One particular feature I am really happy landed in our datacentres is Deployment Groups. With it you can target sets of machines where you are going to deploy your applications on.

It is really amazing because it enables scenarios like Rolling Deployments for your existing applications running on-premise. These patterns are not an exclusive of the big boys!

For example, I am targeting a two node cluster with a very simple ASP.NET MVC application (running on full .NET Framework, so no .NET Core or anything that fancy, pretty much the run of the mill internal application you might find in pretty much any company) like this:

I am targeting one server at a time – it comes as a simple option but this is crucial, as you could do them in parallel.

Then it is fairly straightforward: stop the node draining all the connections (this is quite important) stop the website, deploy the package via the trusted MSDeploy, restart the website and re-join the node.

To handle the cluster nodes, you can easily use the NLB PowerShell cmdlets:

This Release definition is going to run against each of the nodes, making individual node management very easy. Of course it is just a starting point and I am simplifying some of the situations you might find, but all the foundation is there!

Selective branch indexing with TFS and the Search Server

Thu, 29 Mar 2018 10:21:00 +0000

Team Foundation Server’s Search Server can be tough. I mean, it works really well but it takes a certain degree of planning, otherwise it can easily sink your instance’s performance.

I’ve mentioned in the past that there are scripts from the Product Team that help with the daily administration of the server, they are still the number one choice IMHO from an admin point of view.

But it’s not all command-line. For example, if you look into the Version Control settings of your Team Project, you will discover that each Git repository has a nice setting for selective indexing.

This makes a lot of sense, so you can only index the common branches and have a rational use of your Elastic Search instance.

There is an excellent reason for that: you don’t want *all of your branches* to be searchable. They will feature a ridiculous amount of duplicates, hence you would be wasting resources.

Something strange with SQL Server AlwaysOn Automatic Seeding and TFS

Wed, 28 Mar 2018 08:44:00 +0000

I ran into this strange issue the other day in my homelab, and it is worth sharing it: I was trying to setup a highly available Team Foundation Server data tier with AlwaysOn Automatic Seeding instead of the usual backup and restore process, but the TFS_Configuration database (for some reason) was not collaborating.

Automatic seeding of availability database 'Tfs_Configuration' in availability group 'TFSAG' failed with an unrecoverable error. Correct the problem, then issue an ALTER AVAILABILITY GROUP command to set SEEDING_MODE = AUTOMATIC on the replica to restart seeding.

We are talking about a plain, empty instance, so... it was a bit of a needle in a haystack!

Let's take a step back: SQL Server AlwaysOn Automatic Seeding is a new feature of SQL Server 2016 and above that manages to sync up a database in an Availability Group without leveraging backup and restore. This is a life saver in certain situations, so that you can avoid the computational load of a backup and of a restore that might take a long time.

There are some constraints - above all, the instances making up the Availability Group must be *identical*. Yes, identical in everything, including paths used by SQL Server. It is a very cloud-first approach at the end of the day, where you have identical, commodity resources at your disposal and your actual target is to provide a friction-less experience to whom is going to consume the service you'll offer.

So cool, right? Still, for some reason, my Configuration database didn't stream from Primary to Secondary replica. I checked the DMV, and I got an obscure 1200 failed_state error - Internal Error.

The first thing I did (as the instances are really identical, they were provisioned the day before) was to check that I was on the latest CU, as there are fixes available for Automatic Seeding. Check.

I had a look at the script used by the wizard to add the databases to the Availability Group, nothing too fancy to be fair. Reading around seems that there is still a chance that things might suddenly break, so I took another path.

Yes, a Full Backup (taken with the TFS Administration Console nonetheless) was supposed to be enough to enable Automatic Seeding as the recovery chain is started. Would another Transaction Log backup hurt? I don't think so.

After taking the faulty database off the Availability Group, I ran the speedy Transaction Log backup and added the database back in the Availability Group with the script. Guess what, it worked! And my new TFS instance is up-and-running.

Of course this is totally transparent as usual for TFS, as the configuration wizard is smart enough to set the right connection string from the beginning. But you still need to make sure the Availability Group is correctly set, otherwise at the first failover you will be left with nothing.

How Team Foundation Server saves you from a potential mess with IIS and SSL

Wed, 14 Mar 2018 12:07:00 +0000

This is an example of how TFS is robust enough to prevent you doing silly and potentially costly (in terms of time) mistakes.

Let’s say you are configuring a new instance, and you just got your SSL certificate installed on the machine. So you select the HTTPS and HTTP option in the configuration settings, and you select your certificate. And you get an error:

Clicking on that link creates the correct bindings for that certificate. Fair enough.

But the Public URL is not what you like, so you change it to something else. And you go ahead. The result?

The readiness checks prevent you from doing this. It also checks for SNI validity amongst the other things, something that comes handy when you deal with Chrome.

Not all is lost if your cube gets corrupted…

Thu, 01 Mar 2018 15:47:00 +0000

I ran into this very odd situation yesterday with the Reporting capability of my production TFS instance – I realised the Incremental Analysis Database Sync job and the Optimize Databases job were running for hours!

I stopped the Incremental Analysis, and the Optimize Databases job completed successfully. Fine.
But – for whatever reason – my SSAS cube got corrupted! I couldn’t even connect to the Analysis Engine with SSMS. I also found errors in the Event Viewer pointing at a corrupted cube:

Errors in the metadata manager. An error occurred when loading the 'Team System' cube, from the file, '\\?\<path>\Tfs_Analysis.0.db\Team System.3330.cub.xml'.
Errors in the metadata manager. An error occurred when loading the 'Test Configuration' dimension, from the file, '\\?\<path>\Tfs_Analysis.0.db\Configuration.254.dim.xml'.

Now, what to do? It looked like a full-blown rebuild was in order, and it is a costly operation, given that what the rebuild does is dropping both the data warehouse and the SSAS cube, rebuilds the warehouse with data from the TFS databases and then rebuilds the cube.

It is not like being without source code or Work Items, but still… it is an outage, and it is painful to swallow.

Now, in this case the data warehouse was perfectly healthy – the report shown an update age just a few minutes old. So all the raw data in this case is fine, and all you need to do is to rebuild how you look at this data.

The SSAS cube is just a way of looking at the data warehouse. If your warehouse is fine, just wait for the next scheduled Incremental Analysis Database Sync job to run, it will recreate the cube (thus making the Analysis Database Sync job a Full one rather than an Incremental one) without going through the full rebuild.

Why didn’t I process this myself by using the WarehouseControlService? Simply because the less you mess with the scheduled jobs the better it is hiccups happen, but the system is robust enough to withstand such problems and pretty much self-heal itself once the stumbling block is removed.

Containers and DevOps: where are we? Some of my thoughts.

Tue, 27 Feb 2018 20:39:00 +0000

I spent most of February talking about Containers from the DevOps perspective – why you (might) ask? Well, the reason is pretty straightforward: if you are a newbie and you are trying to find resources on containerisation technologies (not just Docker and Kubernetes then!) you will mostly find developer-focused articles, closely followed by C-suite overviews.

Hey, it is totally understandable, don’t get me wrong. They are the hip and cool technology to be aware of in 2018, the market moved and – admittedly – they are a brilliant idea.

The problem is that I believe (and this is a personal opinion) this drive to understand what containers are is skewing the market. Containers are not “like VMs, but better/cooler”, they exist to serve a business purpose.

This business purpose is twin-faced: one appeals to the technological person – you can run the same bits(meant as code, configuration, and toolset) everywhere with some resource tuning, and you are basically pushing Infrastructure as Code (another buzzword, but so 2017…) to the limit. And this is very cool.

But the other side of the business purpose – and the most important one IMHO – is that you can literally change how complex applications are deployed, maximising resource usage and enabling scenarios (blue-green is the first one I can think about) that were exclusive to the OTT before.

This is what really matters.

And to be totally fair with you, containerising an application is not that hard – but it won’t magically improve, it would remain a legacy application running in a container instead of a VM or a physical host.

On the other hand, an application which actually adopts the philosophy behind containers has more chances to actually bring a tangible benefit to the company as it naturally adopts many best practices from DevOps.

Yes, it is unavoidable – whenever you see Containersyou cannot avoid DevOps.

There is only a mistake you should never do. Containers are not DevOps. DevOps collates together practices and concepts that fit in perfectly when using Containers, it’s not enabled by Containers. You can do DevOps with anything, including Containers.

The two together are a match made in heaven. Just don’t forget they are not the same thing.

A quick look at the new SonarQube tasks for TFS and VSTS

Fri, 16 Feb 2018 16:58:00 +0000

Last week SonarSource released a new version of their tasks for TFS and VSTS, with a couple of very welcome additions.

Up to v3, we basically had to do everything manually – especially passing parameters with the /d:… switch.

v4 introduces a context-aware switch where you can specify what you are using for your build:

The Use standalone scanner is quite interesting, as it guides you towards providing a .properties file:

Also, gone are the days of using /d:… inline. There is a very handy Additional Properties textbox to use with a line-by-line parsing, which makes property override very easy to do:

Tasks are also split now into Prepare Analysis, Run Code Analysis and Publish Analysis Result, to allow a more streamlined design of your Build Definition.

Build Agents losing connection after switch to HTTPS

Thu, 08 Feb 2018 12:04:00 +0000

A quick one I am dealing with these days – if you switch the Public URL of your Team Foundation Server to HTTPS you might see your Build Agents losing connection with the server.

This usually happens because of a known bug in TFS an OAuth token isn’t registered so all the authentication tokens on the agents expire.

Of course YMMV, so always double check with Support before running a Stored Procedure on your production instance.

If you happen to get into this problem, you can mitigate it by reverting your HTTPS switch-on and changing the Public URL back to the HTTP version. Doing that will re-establish the connection between the server and the agents.

Tips on dealing with WinRM and remoting using the Test Agent

Mon, 22 Jan 2018 17:29:00 +0000

Despite the push we’ve seen in the last few years, the Hosted Build Service might not be the right product for you for whatever reason.

Then, if you are in a situation where your agents aren’t running in the same domain as Team Foundation Server’s and you want to use the Test Agent then you really risk opening the Pandora’s box, courtesy of WinRM and PowerShell remoting.

And to be completely clear – I have nothing against them the only downside is that they need to be approached in the right way, otherwise the can-of-worms effect is just behind the corner.

First and foremost, remember that whenever you target a machine for Test Agent deployment you only need to consider the Build Agent-Test Agent relationship. All the errors you will get are going to be from the Test box, not the build box.

So when you need to configure WinRM, the Test box is the machine that is going to be accepting the connections. While it sounds straightforward, sometimes things happen and one is tempted to look at the Build box first: don’t.

Also, if you really want to use HTTP and WinRM, remember that this is the trickiest combination – so think twice before going down that route!

Then in terms of errors – you will likely face WinRM errors of all sorts. The most common is this:

If you are outside a domain then REMEMBER about Shadow Accounts – it is the only way to keep identity issues to a minimum. You’ll also need to set the TrustedHosts value to the machines pushing the agent.

Then this:

Remember that passwords need to match, and that mixing users at setup time isn’t really a good idea if you are going down the workgroup/non-trusted domain route.

Always triple check passwords, and I recommend to use the same account for both provisioning and execution, at least as a baseline. This will make sure you have a safety net incase things don’t pan out as expected.

Eventually there is this error, that really puzzles me:

This is actually an aggregated exception:

Look at UAC and execution context for this – it always happens when you are not running stuff as Administrator when that’s supposed to be elevated. It always drives me mad.

Don’t overlook the details during a TFS outage

Wed, 10 Jan 2018 21:11:00 +0000

Two weeks ago I dealt with a head-scratching outage. A few minutes of downtime, for a very stupid reason.

So, we are starting in a situation of total outage. All the services which rely on the production AlwaysOn Availability Group cannot connect to the server. People start screaming, emails flow in at a rate of tens-per-second… well it wasn't that bad, but you get the idea 😊 outages are always annoying.

So off we go with the usual stuff – the TFS Management Console does not load any data from the Data Tier, so the first point of call is checking the database servers.

Which are humming along totally fine. What the hell?! The network stack works as expected, I can ping all the machines involved!

When checking the database servers, I can see that the Availability Group is totally fine – everything is green, synchronised and with no issues. While this is very good on its own (no backups to restore, nothing to sweat too much about), it still does not explain why the Application Tier cannot talk to the Data Tier.

Then the awakening – whenever I try to connect to the AlwaysOn Listener I get a network error, while going directly to the database server works without problems. There it is!

Pinging the Listener does not work indeed. But why? All the cluster resources were green, online.

But for some reason the affected resource failed to perform its duties.

Given that all the other moving pieces were perfectly fine, a manual AlwaysOn failover solved the problem. The lesson learned here is that in a complex architecture there is always something unnoticeable but critical – it’s like breaking a malleolus.

Help! My TFS automatically redirects HTTPS to HTTP!

Thu, 21 Dec 2017 08:01:00 +0000

If you are deploying HTTPS to TFS and you want to keep HTTP for a while, you might experience a strange behaviour: despite following the documentation, every time you browse to your TFS Web Access with HTTPS you are redirected to HTTP.

Fairly simple answer to this, and it is not because of any extra tool or technology: it has to do with the Public URL (it used to be called Notification URL) you set on the TFS itself.

If you leave the HTTP version over there you will always get the HTTP version – even with HTTPS – otherwise if you switch to an HTTPS URL there you will get the HTTPS version by default, and explicitly browsing the HTTP version keeps you on the non-secured protocol so you can keep them side by side.

The impact of an upgrade to Team Foundation Server 2018

Tue, 19 Dec 2017 17:17:00 +0000

Usually upgrading Team Foundation Server is smooth and easy, but there is an exception this time around. It is not strictly related to TFS per-se, instead the issue lies with the new deprecations introduced with version 2018.

If you have a local server with just a few users it might not be a huge deal, if you have hundred of users spanning across timezones all over the world things can get hot pretty quickly. I am not going to cover pre-requisites like versions of Windows, SQL Server, etc. but I want to focus on which are the deprecated features of the product.

Let’s take a look at what these deprecations are, and how to approach them to minimise service disruption.

XAML Team Build

The elephant in the room is clearly about saying farewell to the XAML Build. After 12 years it is time to say goodbye to the old system and move to the new Team Build.

While this is good news for some, it can be troublesome for others, especially if you have a complex Build Definition which hasn’t been updated for years.

The way to go here is to have a clear idea of what the build process does and try to replace it with as many OOB tasks as possible. Second choice would be to cherry-pick from the Marketplace, and eventually write PowerShell scripts.

You might be tempted to reuse existing scripts or automations – which is good – but my suggestion is about maintenance: less legacy scripts mean less problems when it comes to maintaining the process, and using OOB tasks makes easy to take advantage of the constant flow of upgrades you will get from the tasks.

SharePoint integration

SharePoint and TFS 2018 is no longer tightly coupled with SharePoint. This does not mean you will lose any of your Document Library, but only that some features won’t work anymore.

The impacted features are:

· SharePoint site creation when requesting a new Team Project

· Web Parts integration

· The Documents pane within Team Explorer

While this is a major change in the history of the product, it is not unexpected. In an era of APIs and extensibility, relying on some opaque integration which isn’t really fit for purpose anymore – it does not work with Office 365… – isn’t the way to go. But remember: the hyperlink field in Work Item Types is not changing, so you can still link your (now external) documents to Work Items.

The existing Excel reports and the Reporting Services reports are not affected by this change, they will still work normally as they leverage on different features of the product. What is going away is the tailor-made integration which nobody else can use, really.

Lab Management deprecation

Lab Management in its current form will be deprecated and removed. This does not mean you cannot use virtual testing environments anymore – there are a couple of choices. You can use Deployment Groups or the SCVMM task if you want to keep using what you are used to.

It is also worth mentioning that the MTM integration for Lab is going away too – not a huge surprise given how good the web interface is, but it is worth mentioning if you are a heavy user of Lab Management.

Team Rooms

This is pretty much the only feature that is removed with no replacement – again, for good reason: Teams, Slack and others are such good collaboration tools, which focus only on having a good communication experience so they are the prime candidates for adoption.

An unusual scenario for Release Management, part 2: production SonarQube upgrades

Mon, 04 Dec 2017 09:42:00 +0000

In the previous post we saw how you can automate SonarQube test upgrades, but now it is time for production.

As mentioned, my artifacts here will be the TFVC repository, and I am going to have just one environment as target: Production.

There are three phases here, two Deployment Group phases and an Agentless phase. This is also where Tags come into play:

The Release Definition itself is going to be fairly straightforward – after all, I am assuming testing already happened so this automation is just aimed at saving time:

The first phase will prepare the environment for the upgrade itself. It is going to copy the zip file to the location we’d like to use, unblock and extract the ZIP file, copy the plugins in use to the new instance and so on.

I am also using these variables to keep the process reusable, and I am taking the ALM Rangers template as a starting point, so everything will happen into C:\sq\:

The Start SonarQube Interactive launches StartSonar.bat from PowerShell to make sure it is not going to make the task hang and run indefinitely.

The Agentless phase is required because once you launch StartSonar.bat you will have to browse to the /setup URL and start the upgrade process.

I am going to get a notification (it could be anyone else here, even a group) and I am going to start the process. You could automate that, but it is surely better to do so manually IMHO.

Once the upgrade is completed (and you stopped the StartSonar batch job, again I could automate this too but I am happy to have it included in the manual interaction for now) you can resume the pipeline with the second Deployment Group phase, which is going to remove the old service, install the new one and start it using the OOB batch scripts in your SonarQube instance.

This saves time (remember you can schedule this Release Definition too ) but the most important takeaway here is the value you get from automating the process and versioning your configurations.

It might be unorthodox, but it works quite well IMHO.

An unusual scenario for Release Management, part 1: testing SonarQube upgrades

Fri, 01 Dec 2017 10:01:00 +0000

Among the many things I do I manage a SonarQube instance. Not a big deal to be fair with you, but it is a valuable tool and it has its quirks. You need to spend time on it.

So I thought about automating this process a little bit. It is a bit unusual, but it brings some value, so why not!

The result is a TFS or VSTS Team Project with a TFVC repository (TFVC is perfect for handling binary files!) and two Release Definitions, one for Test and one for Production.

The reason why there are two Definitions is because – oddly enough – the Test one came after the Production one (which is easier, you’ll discover why later on). I might revamp the whole thing in the future to have sequential environments, but this is it as of now

In the TFVC repository you are going to find folders for each SonarQube version I deployed on my server, together with the relevant sonar.properties file filled with the values you want, and a scripts folder with some utility scripts.

The reason why I am not automating the configuration file creation (via a find-and-replace operation for example) is because you are explicitly told by SonarSource not to just replace this file with an existing version but to start from scratch.

While testing your configuration you will need to work on it anyway, so it is a good idea to put it in a repository, and you will get versioning for free as well. Bonus.

Both my Release Definitions feature a Deployment Group: guess what, it contains my SonarQube server I also leveraged on Tags, in case I might want to have completely separate enviromnents, as the Deployment Group phases are marked to run only on machines that sport the right tag for the Release Definition. It isn’t the case for now though.

Now it comes the fun part, let’s start with the test upgrades. My process for testing SonarQube is as it follows:

Restore a backup of the production database
Get the new SonarQube version on the VM that hosts its services
Extract the new version, set the right values in the sonar.properties file (like different ports and java switches)
Check that the upgrade runs successfully
Verify all the involved plugins

Like I said I am not going to automatically find and replace values in the sonar.properties file, and the latter steps aren’t really worth scripting, but the first two steps can benefit from an automated process.

This is what my testing pipeline looks like:

Nothing too fancy, but it saves time.

The cool bit here IMHO is the Azure PowerShell script I am running to restore the database: given the Resource Group, Server, Database and SonarQube version (which is used to form the name) I can check if I already have a testing database – if not it starts restoring a backup copy from ten minutes before.

If this prerequisite check fails, I integrated the error handling so it stops the task immediately and marks the release as failed:

How? Like this:

The Write-Error statement stops the task execution and raises the error message, the Write-Host statement with the specific ##vso line marks the task result as failed and the exit 1 line terminates the sessions so that whatever is next (the database restore!) is not executed.

Eventually at the end there is an Agentless phase which is just manual intervention with the required things to do:

I will go through the production pipeline in the next post, as it is different

Old but still very good, SlowCheetah with VSTS!

Mon, 20 Nov 2017 13:05:00 +0000

I was asked if there is a way of transforming configuration files at build time. Nothing else than the good, old and reliable SlowCheetah if you ask me

Just install the Extension, and you will be able to add your transformations by right clicking the .config file and selecting Add Transform:

These are going to be based off the BuildConfiguration you defined in your Solution. Once this is done you can define your own settings, like this:

where a transformation can be something like this:

There are so many examples on how to do this, so please do not shoot on the pianist all of that goes into a Version Control System of sorts, and it can be built by VSTS or TFS or any other Build Engine.

Your Build Definition needs to specify a Configuration, either at Queue time or embedded into the Build Definition itself.

The result? As expected:

This isn’t really about VSTS or TFS per-se, but it is always a valuable approach to configuration management, and it was worth a refresher

YAML Build Definitions in the Team Build, now what?

Mon, 20 Nov 2017 10:25:00 +0000

Among the news and announcements from Connect() you surely saw YAML Build Definitions mentioned, and you might wonder – what’s coming? How does this fit into the overall TFS/VSTS product?

Let’s start from the past, from 2011 – this UserVoice request asks for something that enables versioning for Build Definitions.

Being 2011 many things weren’t as available or as robust as of today, and the current Team Build was not remotely on the horizon. Fast-forward six years, and we’ve got YAML Build Definitions.

Didn’t we have a way of tracing Build Definitions without YAML? Really? Six years to implement some kind of traceability? Well…:

There is a built-in Compare Difference feature in both TFS and VSTS, and you can export your Build Definitions in a JSON file. So no, it is not just about traceability.

In the age of Continuous Delivery, Infrastructure as Code is critical. It saves an enormous amount of time and resources, and it is an extremely reliable way of automating the build and release process.

That is where YAML Build Definitions fit into the equation: they represent the concept of Infrastructure as Code pushed to the limit. You are not just treating the deployed infrastructure as code, you are also adding the deployment infrastructure in this definition, where as long as you have the required resources at your disposals (agent queues, build tasks, etc.) you are good to go.

This also does not mean the current Build Definitions are leaving – YAML is just for the Build Definitions, but the underlying technology is still the same. Also, with YAML you don’t get a visual breakdown of the tasks of the Build Definition:

It is a different way of doing the same thing – it might not cater for everybody (I am a big fan of the current Definition UI because it makes it understandable for everybody regardless of the expertise and the role), but it adds options for someone who needs a different experience and has different requirements.

At the end of the day, the more the better

Unorthodox reporting with TFS/VSTS and PowerQuery

Mon, 06 Nov 2017 12:11:00 +0000

I am a huge Excel fan, because it allows easy data transformation and its flexibility is second to none, despite its complexity. But I also use other tools, depending on the requirements.

Many users instead only use Excel, with no possible alternative. Good or bad, this is the norm in many organisations and trying to change this habit too early while trying to push new concepts or ideas only puts strain on these users, raising barriers and potentially preventing the very change we are pursuing.

That is where PowerQuery comes to the rescue. Ironically enough, I discovered it by accident trying to help my partner with some stuff from her work (she is a heavy Excel user) – PowerQuery is a very powerful data analysis engine (it goes hand to hand with PowerPivot, another Excel Data Modelling tool I am really fond of!) that, in a nutshell and from a developer point of view, enables database-like querying and reporting scenarios.

So what can you do with it? Well, let’s take a very easy example: you have a TFS/VSTS query which returns all the non-done PBIs in a backlog, and you want to report on this query so you will know how many Work Items you have in a certain state, but without using TFS or VSTS at all.

That is where Excel comes easily to the rescue: you can connect it to TFS/VSTS with the Team Add-in, downloading the raw data from the query you saved there:

Select the raw data you want to use and from the Data ribbon, select From Table. Excel will automatically recognise the data source you want to use, if you don’t select data beforehand you’d have to input the range manually.

PowerQuery now kicks in:

What we want to do is pretty easy and straightforward, so we are going to use Group By:

A basic group by works well here:

If you use an advanced one you can group by based on multiple columns. If you have bugs as well as PBIs as requirements, that’s what you want:

Now, if you Close & Load, you are done. How is this useful in any way?

Easy: this query is going to show on the side of your spreadsheet:

Click on the Query you created, and you will be immediately shown the result:

Moreover, it is quite dynamic.

Going deeper on it, the name isn’t cool at all – VSTS_<GUID> doesn’t say much. You can change it in the Query Editor:

Underneath you can see the Applied Steps – that is where things get interesting:

It is the visual representation of all the data transformation you applied. If you want to access these steps and change them, click on the Advanced Editor:

You will get the actual PowerQuery raw language (it is a functional language called M by the way ):

This is where you can start creating your custom transformations, leading to dynamic custom reports based on TFS/VSTS data.

I really find it cool and fascinating to be fair, bringing together such different user requirements and scenarios – without mentioning that you can up your percentage of Excel knowledge by a notch, which is always a great skill to master

Help! I cannot complete my Pull Request in TFS!

Fri, 13 Oct 2017 09:46:00 +0000

A quick one today: if the Complete button is greyed out in your Pull Request UI, ask your TFS Administrator to start the TFS Job Agent.

The TFS Job Agent does many things – including handling Pull Requests completion.

Successfully handle disruptive changes with no downtime: the TFS 2015 example

Tue, 10 Oct 2017 10:10:00 +0000

It is something I’ve mentioned a few years ago but the question came out again during my presentation at x-celerate.de:

How should I handle a breaking change without service interruptions?

This is a brilliant question, and the best example I can give out is the TFS 2015 Upgrade that introduced support for renaming Team Projects.

If you don’t want to have downtime for your users the only mitigation is to introduce an intermediate migration layer which is going to be pouring data from the production stack and transform it into what you want.

The upside of this is that you are performing a very expensive and time-consuming operation out-of-band, so you can apply all the usual patterns for highly available application deployments.

The downside is that it is a costly operation, it could be compute, storage or something else but it will cost something out of it.

In my specific case I was able to perform a scheduled upgrade into the mandatory weekend window (yes, there was still a bit of downtime but it was due to the nature of the product and it was expected – you can overcome the hurdle if you are building your own product though) instead of having days of downtime due to the migration of data from a schema to another, at the cost of lots of storage space for the temporary tables and a dedicated server to run the tool.

Re-release to an environment, don’t spin up a whole new deployment!

Sun, 08 Oct 2017 10:31:00 +0000

I know this happens on a regular basis – but it caught up my eye this morning as I am finishing up preparation for X-Celerate.de.

Let’s say your Release fails:

What many do is to actually spin up a whole new instance of the Release itself. While this works ok, you are missing out on something important: traceability.

In a sea of releases, with microservices and multiple moving pieces, how would you be able to trace back what happened during that failed release?

Why don’t you actually try to re-deploy the same failed bits instead?

Doing this provides you all the details about the previous failures, and it is going to be much easier to recall in case you might need to refer to the scenario in the future.

Oh in case you were wondering… it was all about my lab’s DNS server, which cached the Kudu website of an App Service I was deploying as 404 but it is Sunday after all…

If you don’t package your stuff you are doing it wrong!

Thu, 05 Oct 2017 15:01:00 +0000

Packages are a thing, exactly like containers are.

I mean – who wants to spend countless time in moving files, editing configuration files and the likes? Nobody, I know, but still so many people don’t take advantage of application packaging when it comes to deploying stuff!

Let’s take an average web application as an example. What is the reason that pushes you to actually move stuff from a certain folder (DLLs, .configs, etc.) to the target server, instead of packaging your application’s components and move these instead?

All you need to do is adding /p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true to the MSBuild Arguments if you are using a traditional Build task.

If you are using .NET Core you just need to select the Zip Published Projects in the Publish task!

I just love the MSDeploy comeback. I am a huge supporter of this technology, because it makes life so much easier. It also has the side effect of enabling deployment to Azure in a snap, as it is one of the three supported delivery methods!

Let’s say you have a Build Definition and a Release Pipeline for this application. You want to deploy it to Azure – this is what you need to do:

What if you want to run the same application (providing it actually works on-premise as well and it does not specifically require any technology not available in your datacentre) on your own servers?

Firstly you’ll need to create a Deployment Group in VSTS – this can be done either by statically running the appropriate PowerShell script on your machines (interactively, via RDP) or dynamically with a bit of PowerShell or Azure if you are using IaaS. It is required because IaaS/on-premise machines in a Deployment Group will run an agent.

Then you can run whatever script you need to install the pre-requisites your application requires and configure all the settings, and eventually you can use the IIS Web App tasks to interact with IIS. Focusing on the IIS Web App Deploy task…

That Package is exactly the same package I used in the Azure deployment above. So you can easily have a Continuous Delivery pipeline on Azure and a different one (with the same cadence or a different one, your call) for on-premise, both starting from the same artifacts.

Containers are better – of course – but they require a minimum or ramp up or learning in order to actually implement them in a production environment. Moving to MSDeploy on the other hand is a matter of minutes at most, and it will provide a tangible improvement.

A few catches on customising the new Work Item form

Fri, 29 Sep 2017 08:51:00 +0000

If you use Team Foundation Server 2017 you already know this:

The new form is brilliant: it makes a much better use of the screen space, with a better UX in general.

But what if you have forms that were already using customised fields and a specific arrangement of controls?

The answer is that Microsoft uses a best-effort transformation system to automatically migrate your old form to the new, but for some reason I found myself in this situation – these two tabs won’t migrate to the new layout.

The new customisation model is brilliant – everything is now much cleaner and easier to use. All you need to do is add what you want to the <WebLayout> tag:

You can see that you now have Page, Group, Section as containers for controls, making life actually much easier when it comes to customisation. In my case I added two new Pages with the relevant control in there:

Of course you can customise the display layout by using the LayoutMode attribute. All the documentation is available here.

How to encrypt your Team Foundation Server data tier

Wed, 20 Sep 2017 11:26:00 +0000

For all sorts of reasons (including GDPR looming on you) you might feel the need to encrypt your Team Foundation Server databases. Proper encryption at rest.

I realised this is not a really well documented scenario, but it is surprisingly easy to achieve.

What you need to do is leverage SQL Server TDE (Transparent Data Encryption), which is out-of-the-box since SQL Server 2008 onwards. It acts at page level and it is transparent, with little overhead.

The process of enabling TDE is very well documented, and it is based off two keys (the master key and the encryption key) and a certificate. It is very straightforward if you have a single server as a data tier, off you go.

Now, this gets slightly more complicated if you have (like me ) AlwaysOn protecting your High Availability. Well, complicated if it is the first time you approach the topic.

Working with AlwaysOn requires:

On the Primary Replica - creating the master key, the certificate and the encryption key. Remember to backup the master key and the certificate.
On the Secondary Replica - creating the master key and the certificate. The certificate must be created from the backup of the Primary Replica!

After these two steps you can enable TDE on the database hosted on the Primary Replica, which then will propagate on the Secondary as per AlwaysOn schedule.

If your databases are already encrypted and you want to add them to an Availability Group you’ll need to do so manually – the wizard is not going to show encrypted databases to be added to the AG.

This SQLServerCentral.com article features a set of queries I found really helpful to get started.

A suggestion though: prepare a single query for the Primary Replica preparation, run it, prepare a single one for the Secondary Replica preparation, run it, and eventually encrypt from a separate query.

The reason why I say this is simple: if anything goes wrong before you encrypt the database you can easily drop the master key, the certificate or the encryption key and start again.

Eventually, remember that encryption for large databases can take a long time. During this time, the process might stop because of database size, so remember to check the logs as well so you can restart it if you need to.

Why Work Item rules are so important

Tue, 19 Sep 2017 14:09:00 +0000

I was on holiday for the last couple of weeks so I had only a limited coverage of what happened since the beginning of the month but I could not miss the release of custom Work Item rules on VSTS.

Why such an emphasis on my end? Well, because custom rules on Work Items involved fiddling with xml files and command line tools or using the Process Template Editor in Visual Studio and a UI that is a bit tough.

It is something that any TFS administrator does on a regular basis though. Now rules in VSTS can now be defined in a web UI with a consistent experience and multiple sets of conditions and actions can be defined easily in the same page.

Also, this makes involving team managers in the definition of these rules extremely easy, as there is no Visual Studio, XML, command line involved anymore.

You might not know this: Service Execution History in VSTS

Wed, 30 Aug 2017 16:08:00 +0000

How would you know how many times your Service Endpoint is invoked, with what result and by who?

It is neatly after the Details and Roles tabs in the Service Endpoint list for each Service Endpoint

Shadow code indexing jobs after upgrading to TFS 2017.2

Fri, 18 Aug 2017 14:31:00 +0000

Just a quick one – if you remove the Search Server before upgrading to TFS 2017.2, you might see failing Git_RepositoryCodeIndexing or TFVC_RepositoryCodeIndexing jobs raising a Microsoft.VisualStudio.Services.Search.Common.FeederException: Lots of files rejected by Elasticsearch, failing this job error.

The reason why this happens is because the extension is automatically enabled on the collections, triggering these jobs.

So check your extensions after the upgrade

Run a SonarQube analysis in VSTS for unsupported .NET Core projects

Thu, 10 Aug 2017 08:48:00 +0000

With some projects you might face this:

error MSB4062: The "IsTestFileByName" task could not be loaded from the assembly <path>\.sonarqube\bin\SonarQube.Integration.Tasks.dll.

It is a known issue I’m afraid, involving (among the others) .NET Standard.

There is a fairly straightforward workaround IMHO. Instead of using the Scanner for MSBuild as you would, use the CLI scanner that is now provided by VSTS:

This is enough to let the scanner do its job. This approach can bring a different issue – if you use branches to identify projects in SonarQube, or if you have dynamically set properties, and having a fixed, static properties file doesn’t really work.

Still, nothing really blocking. Do you see the PowerShell Script above?

This is an example of what you can do – a bit rough, it just adds a line at the end of the file stating the branch to analyse. It can also be much cleaner, but still

Remember that you can always manipulate files in the agent, and that’s what I do. Add whatever line you want with a script like this so that you have granular control in the same way as adding /d:… to the parameters in the regular MSBuild task.

My take on build pools optimisation for the larger deployments

Mon, 31 Jul 2017 20:09:00 +0000

If you have a large pool of Build Agents it can be easy to incur in a terrible headache: plenty of hardware resources to handle, capabilities, pools, queues, etc.

Bearing this in mind, having a single default pool is the last thing you want IMHO:

There are exceptions to this of course, like if you work on a single system (loosely defined, like a single product or a single suite of applications) or if you have a massive, horizontal team across the company.

Otherwise pulling all the resources together can be a bit of a nightmare, especially if company policy gets in the way – what if each development group/product team/etc. needs to provide hardware for their pools?

Breaking this down means you can create pools based on corporate organisation (build/division/team/whatever), on products (one pool per product or service) or on geography.

Performance should be taken into account in any case: you can add custom capabilities marking something special about your machines:

Do you need a CUDA-enabled build agent for some SDKs you are using? Add a capability. Is your codebase so legacy or massive that takes advantage of fast, NVMe SSDs? Add a capability. You get the gist of it after a while.

That becomes very nice, because with capabilities you can define your perfect build requirements when you trigger the build, and the system is going to choose the one that has all you need – saving you the hassle of manually finding what you need.

Maintaining these Build Agents is also important – that is why a Maintenance Job can be scheduled to clean up the _work folder in the agent:

This can have an impact on your pools – that is why you can specify that only a certain percentage is going to undergo the job at once. Everything is also audited, in case you need to track down things going south.

So many things I like in the new Release Editor!

Wed, 26 Jul 2017 17:13:00 +0000

Change is hard to swallow, it is the human nature and we cannot do anything about it so like every change, the new Release Editor can be a surprise for some.

To be fair with you, I think it is a major step ahead, for a few reasons. Usability is on top of the pile of course, as I can have a high level overview of what my pipeline does without digging into the technical details of the process.

Then if you look at the Artifacts section, you will see the amount of sources you can choose from:

Being VSTS a truly interoperable DevOps platform spoils you for choice – I really appreciate the having Package Management in such a prominent place, because it enables all sorts of consumption scenarios for NuGet packages as a build output, including a cross-organisation open model.

Then on the Environments section, the templates provided cover lots of scenarios and not only with cloud technologies. One that is going to be really appreciated in hybrid DevOps situations is the IIS Website and SQL Database Deployment.

This template creates a two phase deployment that serves as a starting point for most on-premise deployments with IIS and SQL Server.

The Web App Deployment supports XML transformations and substitutions by default:

The data side of the story is really interesting IMHO as it employs DACPACs by default, together with a .sql file and inline SQL options:

I think it is clear I really like it

Git, TFS and the Credential Manager

Tue, 11 Jul 2017 13:00:00 +0000

A colleague rang up saying he could not clone anything from the command line, but everything was fine in Visual Studio. All he got from PowerShell was an error stating he was not authorised to access the project.

He did not want to setup a PAT or SSH keys, and this behaviour was quite odd to say the least. There was also a VPN in the mix.

At the end of the day the easiest way to get around this was using the Windows Credential Manager:

Some tips on Search Server for TFS 2017

Thu, 29 Jun 2017 12:04:00 +0000

Code Search is a brilliant feature based off Elastic Search. I wanted to summarise a few tips from my relatively limited experience with Search Server for TFS 2017, which adds Code Search to your instance.

The first thing to remember is that the size of the index can be quite large (up to 30% the size of a collection in the worst case) so plan for it in advance.

CPU and RAM should not be underestimated as well. Elastic Search can be a quite intensive process.

If you are not an expert on it (like me ) you want to use these script the TFS Product Team provided. They are straightforward and extremely useful. Also take a look at the documentation, it is very useful as well.

The indexing process can be quite tough on the TFS scheduler, so bear in mind this when you install it – otherwise you will see some jobs delayed.

This should not have an impact on the users (all the core jobs have higher priority anyway), but it is worth remembering that the indexing job will have a similar priority to the reporting jobs, so there is a risk of slowing reporting down.

A few nuggets from using TFS/VSTS and SonarQube in your builds

Thu, 22 Jun 2017 14:39:00 +0000

The cool thing about SonarQube is that once it is set up it works immediately and it provides a lot of value for your teams.

After a while you will notice there are things that might be refined or improved in how you integrated the two tools, here are some I feel can be quite useful.

Bind variables between Team Build and SonarQube properties

I feel this is quite important – instead of manually entering Key, Project Name, Version, etc. you should be using your variables. Try to reduce manual input to a minimum.

Branch support

SonarQube supports branches with the sonar.branch property. This would create a separate SonarQube project you can use for comparison with other branches.

Analyse your solution once

Don’t be lazy and add just a task at the beginning and one at the bottom - you should scan one solution at the time and complete the analysis. This will solve the typical Duplicate project GUID warning you will get if you have multiple solutions in the same scan.

Exclude unnecessary files

It is so easy to add a sonar.exclusion pattern, do it to avoid scanning files you are not interested in.

How a (home)lab helps a TFS admin

Wed, 14 Jun 2017 13:52:00 +0000

I’ve always been a fan of homelabs. It is common knowledge that I am a huge advocate of virtualisation technologies, and pretty much all my machines feature at least Hyper-V running on them.

If you are not familiar with this, a homelab is a set of machines you run at home which simulate a proper enterprise environment. This does not mean a 42U cabinet full of massive servers, but even just a decently-sized workstation acting as VM host would do. The key here is enterprise, so ADDS, DNS, DHCP, the usual suspects indeed, plus your services.

What I am going to talk about is applicable to corporate labs as well, albeit this can be less fun

So, if you are a TFS administrator, what are the advantages of a lab?

Testing upgrades!

Yes, test upgrades are one of the uses of a lab. But not just testing the upgrade itself, it also helps understanding how long an upgrade will take and what are the crucial areas you need to be aware of.

In an ideal world, you will have an exact copy of the production hardware so you might be able to have a very accurate forecast. This helps of course, but it will also hide what are the critical areas in your deployment.

Let’s take TFS 2017 – one of the most expensive steps is the migration of all the test results data in a collection to a different schema.

This is a very intensive operation, and having a lab where you know inside-out any finer detail about your hardware really helps when it comes to planning the proper upgrade, especially if you have a large deployment.

Without mentioning that in case of failure you are not breaking anybody’s day and you can work on your own schedule.

Also, you will find that sometimes you might need to experiment with settings that require a service interruption. The lab is yours, so you are not affecting anybody again and you can go straight to the solution when it comes to the production environment.

All of that sounds reasonable and maybe too simplicistic, but I saw too many instances where there was no lab and the only strategy was test-and-revert-if-fails, given that Team Foundation Server is “just a DB and IIS” (yeah…).

Definitely not something you want to see or hear, trust me

What can you learn from The DevOps Handbook

Wed, 31 May 2017 15:19:00 +0000

I thought about reviewing The DevOps Handbook, but then I realised its real reference value. Books like this, with multiple layers of usage are really invaluable.

This book is gold IMHO, and not just for its cover colour. But let’s rewind a bit.

I bought the book in January, I read the first few chapters then I forgot it at my parents’. Fast forward a few months, my brother comes visiting and he brings the book back, but it is then then left on the to read pile for a while.

Eventually I managed to find time to read it and here I am writing this post.
So why isn’t this a regular review? What did I realise, all of a sudden?

Well, books can be easily read in a few days, a couple of weeks tops. What happened is that each chapter I read was providing insights or mirrored situations I experienced during these months.

Each chapter can be cherry-picked and adapted to your situation, because it starts from a real scenario with real requirements and targets. You will notice patterns going through the book, all the concepts are there but applied in a tailored way to fit the problems one has to face.

I can see this book being a useful guide you might want to refer to when you are tackling a problem, just pick the chapter more akin to the approach you are using and you will feel guided.

Review - Professional Git

Fri, 19 May 2017 09:03:00 +0000

I am asked at least twice in three months about a good book on Git.

Despite the information available at https://git-scm.com/book is very comprehensive, there is value out of a published book to be consumed as a reference, especially when onboarding a new team member or when you finally want to get a firm grip on this (sometimes dreaded) Version Control System.

So I contacted Wrox to get a copy of Professional Git, which was published in December 2016 hence it is not only a reference book but also an updated reference book.

You might wonder why is this so important to me. Well, it is fairly simple after all. Git became a mainstream tool a few years ago, but its history goes much further back. Documentation on its usage might be older, aimed at advanced users or fragmented, so it is important to have a book not only covering all the important topics, but crucially covering them from the right point of view.

Brent Laster did a brilliant job with this book. I felt the level of depth was perfect, neither too shallow nor too deep. Topics like Submodules – often troublesome for some and quite challenging anyway – are covered with a clarity that would make the essential information memorable.

The book has companion exercises and labs to keep you busy if you are a total newbie. If you are a bit more experienced it is still very valuable, putting down in plain language with straightforward samples even the trickiest of topics.

Just remember that the syntax used for the examples is UNIX-style – hence lots of ls! But aside from that I cannot refrain from suggesting it to who wants to start with Git and is looking for a comprehensive guide.

Error 404 when uploading the SonarQube Analysis Report from the Build

Tue, 09 May 2017 15:31:00 +0000

That can be something hard to catch if you don’t know where to look!

I spent some time on this issue – SonarQube’s End Analysis task fails, with either an unhandled exception (version 2.1.1 of the extension) or a 404 page in plain text in the log (with the older 2.0.0).

What was really odd was that the issue happened only on certain projects – some were fine, some others were failing, And it happened regardless of the build server used by TFS – whatever the agent, this randomness was there.

At the end of the day, don’t underestimate logs collected from the Web Server you are using: I found an error 404.13 in the logs, meaning the Analysis Report was exceeding the size limit for the upload.

What to do with WMI errors and Team Foundation Server

Wed, 03 May 2017 09:08:00 +0000

Last week I spent some time on trying to sort out WMI errors in a test environment. That was not fun, but at the end of the day there is something to learn out of it.

Everything starts with this set of errors with an AT-only installation:

Looking at the logs you can see it is pretty bad stuff:

I tried with the usual suspects (wmimgmt /verifyrepository, setting the involved machines as standalone hosts, etc), but they all run fine. One of the suggestions you can find around is to reinstall the IIS 6 Management Tools on the Application Tier:

Still no luck. I tried connecting with wmimgmt.msc and I got all sorts of errors. At the end of the day I temporarily reset the WMI repository on that machine and I then decided to move these test services to another VM. Why?

The WMI repository is not supposed to be rebuilt lightly. It should be the last resort, and I did not want to tie up this testing environment with a potentially problematic machine.

Don’t forget that the Application Tier is just a front-end for Team Foundation Server. You can replace it with another machine and scale out as needed.

Also, the errors above appear in both the Application Tier and Data Tier readiness check category for the AT-only install, despite they only apply to the AT. That is because the machine could not communicate with anything beyond itself (not even itself I would add), so it would report that the Data Tier isn’t reachable. Do not touch the database servers unless you really have to, and the logs are going to tell you if you have.

Quickly share query results with the Web Access

Tue, 18 Apr 2017 15:22:00 +0000

If you really like the Copy Query URL button because it opens a full-screen page with no other link to TFS or VSTS...

You would also know that the query link expires after 90 days. Too bad. Is there a way of getting the same behaviour (without taking into consideration any ACL-specific configuration) without using that link?

Well yes - just add &fullScreen=True to the Web Access URL:

“We don’t ship so often”: why? A reflection on Delivery hurdles.

Fri, 07 Apr 2017 12:58:00 +0000

The last Stack Overflow Developer Survey Results shows that the more a developer ships the happier (s)he is.
Of course we see a huge amount of people checking in multiple times a day, but also a large amount of people checking in (so potentially building and deploying) much less than that.

So, looking at the other side of the medal: why aren’t you shipping often?

Reasons – as usual – are varied. There might be process constraints (certifications, etc.), hard requirements, but I’ve often seen a heavy reliance on older deployment procedures which are considered too expensive to be replaced by automation. Don’t touch what works, right?

Web applications are a stellar example of this. You might have the most complex web app in the world, but why should you manually move stuff around when you can pack everything in a MSDeploy package?

“But that is for Azure and cloud technology and stuff!”

Wrong answer! MSDeploy is around since 2009 and it is well supported on-premise as well! So why aren’t you using it for your existing application? It is, after all, the same concept Tomcat uses for its .war files.

This isn’t about throwing years of valuable content in the sink. It is often a matter of trying to split the larger problem into smaller components, and approaching different delivery vehicles. You can retain your existing application as-is, just replacing how you bring it into your production environments.

How can I monitor my AlwaysOn synchronisation status?

Sun, 02 Apr 2017 07:11:00 +0000

As a Team Foundation Server administrator it is critical to have knowledge of all the components involved by your deployment, and SQL Server is the lion’s share (of course).

As you know I am a huge fan of SQL Server AlwaysOn, a really brilliant High Availability solution. I was wondering if there is a way of having an estimation of where the Database Engine is when you see the Synchronizing state in the AlwaysOn dashboard…

I found out there is a way, and it doesn’t even require any SQL at all. All you need to do is to add the Last Commit Time column on the Dashboard, so you will see the time of the last synchronised commit from the Primary Replica to the Secondary.

Of course it is not an ETA, but it gives a rough idea of how much work is left for the synchronisation.

During this state Team Foundation Server is still available because it relies on the Primary Replica, but remember to not perform any failover otherwise you are going to lose data! If it is a long synchronisation you are doing I strongly suggest to set the Failover Mode to Manual, downtime is always a better trade-off than data loss.

Move TFS databases with no downtime, thanks to SQL Server AlwaysOn

Tue, 21 Mar 2017 14:14:00 +0000

If you follow this blog or my Twitter feed you should know I am a massive fan of SQL Server AlwaysOn.

Recently I restored and moved some TFS databases around, and one of them remained on a temporary storage because of the massive size involved. After a while I managed to sort out the primary storage so I could move this database (and its Transaction Log) back to it.

This what I did, no warranties of course but it worked on my machines!

First of all, you need to be aware that you will have a limited availability during this period. It doesn't mean you are going to have an outage, but that you cannot rely on the Secondary Replica while you work on it. Why? Because you need to disable the Automatic Failover and make any Secondary non-readable:

Then suspend Data Movement from the Primary. This means your Primary Replica is not going to sync with the Secondary.

You will get your database to move in a non synchronised state.

Now note down your logical names for the files you need to move. Use these in the following query, the path in the FILENAME is going to be the new destination:

Run this on all servers. You might want to wait for the Secondary to be up-and-running, but don't forget to run it against the Primary too!

Copy all the files to the new destination, once done restart SQL Server on the Secondary:

Now check that if Secondary is in a green state.

If the Secondary is green, resume Data Movement and after the status is Synchronised again perform a manual Failover so that the roles are swapped. Then perform all of the above on the new Secondary and you will be done.

Eventually, don't forget to re-enable any configuration you disabled before performing this!

Settle your team's disputes with an EditorConfig file

Fri, 17 Mar 2017 11:14:00 +0000

Ok, this is a bit too much :) but it is actually possible to settle some disputes on Visual Studio settings by leveraging on an EditorConfig file.

EditorConfig is a broadly adopted open-source file format that enables IDEs to be set in a pre-defined way so that you can have a consistent set of rules across tools. This is an ideal tool for creating a standard set of settings and guidelines to be adopted across the team, and Visual Studio 2017 now supports this format!

Kasey Uhlenhuth wrote a brilliant description of what is supported in the IDE, and the setting area is very well done with an actual example of what you are setting up.

Then you can configure how to enforce your style rules - bear in mind that errors are treated as such, so they would prevent a successful build!

If found in a solution, the .editorconfig file will override the default settings of the IDE – so to have a team-shared convention all you need to do is put the file into the root of the project folder, job done!

The new connected marketplace experience: how to buy Package Management for TFS

Wed, 08 Mar 2017 10:06:00 +0000

It is not news that in a Hybrid DevOps stack you might have stuff on-premise and stuff in the cloud, Package Management is a prime example of this.

If you don’t have a Visual Studio Enterprise license for any user in your organisation you’d need to buy some users’ licenses for this service. It is billed through Azure even if you are on-premise and totally disconnected from the internet.

You install it on-premise, but you would still set your billing to an Azure subscription when buying it:

Once you are done you can install the extension. Remember: if you have an Enterprise license (either with or without MSDN) you are already entitled to Package Management so you can install the extension straight away.

Also, if you need to manage your users you can browse to the Users hub (<your TFS>/<your collection>/_admin/_userHub) and assign licenses to whoever requires them:

This is exactly like VSTS, but on your on-premise TFS.

Handle your NuGet packages’ qualities with Release Views

Sun, 26 Feb 2017 20:49:00 +0000

Are you building NuGet packages for your tools, utilities and libraries? Check.

Are you using SemVer for versioning? Check.

Then you might want an easy way of offering your (internal) packages, sorting them between Release and Prerelease for example. Release Views is what you are looking for.

What is really brilliant is that you already have a baseline set: Release and Prerelease. You don’t have to configure anything, it is already there for you.

What makes lots of sense IMHO is to divide them into Release, Prerelease and CI.

That’s because even if we would all love to have a single feed where you can get all the packages in an independent fashion, it is highly likely that some users might not need a CI package but something more refined instead.
With the latter it is clear that the package is not as good as a beta, making it easier to section your offer for the user as you like. CI is really bleeding edge sometimes, and I believe it is good to have it separated from other builds.

A note on TFSConfig OfflineDetach

Tue, 14 Feb 2017 16:16:00 +0000

I already mentioned the very useful TFSConfig OfflineDetach in the past. Today I used it once again, and I realised a very important information is missing.

What you need to remember is that the Configuration Database you need to use is the one which has the Collection you want to detach in it. And it must be offline as well.

So in today’s situation (moving a collection across domains in a new instance) I had to restore the configuration database as well as the collection’s.

PRs and ‘Unable to queue Build’ with VSTS

Mon, 06 Feb 2017 14:31:00 +0000

This should never happen, but if it does…

Just go checking the PR settings to verify that there actually is a build linked!

Getting started with Delivery Plans in VSTS

Mon, 30 Jan 2017 10:39:00 +0000

Last week Microsoft released a very interesting extension for VSTS – Delivery Plans.

It is still a very early preview, it will be associated with a business model (so it is likely it won’t be free), and this feature represents a very important expansion of VSTS’ field of execution.

This extension brings a way of tracking the work undertaken by multiple teams at the same time, with the possibility of focusing only on a certain level of detail, and enables scenarios of delivery forecast previously quite hard to achieve.

To easily get started, I suggest installing the Sample Data Widget extension and deploy the “SAFe with VSTS” package. I went for this package because it creates a nice set of Work Items, not because there is any relationship between Delivery Plans and SAFe.

Once this is done, customise the iteration dates and the teams you like – I would go with two sub-teams part of a large team - then assign what you feel is better suited to each team (pretty randomly I reckon given we are just using sample data ) and create a Plan like this:

This is a plan designed to give you a full breadth of information, from the larger parts to the finer details. The result is brilliant:

In a single page you will get a timeline view of Epics and Features delivered per-sprint by the whole team, plus the User Stories delivered by each sub-team. This is obviously overkill for the real world – you will want two different plans depending on the level of detail you would like to provide – but it explains why this feature is so powerful and game-changing for me.

Delivery Plans will enable scenarios where stakeholders can easily understand the status of their value streams without using external reporting tools, and this is a crucial step to allow VSTS to grow from a developement-focused tool to a more general purpose in a company.

The documentation is already very comprehensive, take a look there and I strongly suggest to give a go to this extension, given the value it brings.

Do not forget: only leaves are shown on a board!

Mon, 23 Jan 2017 13:13:00 +0000

This is a classic question I get at least once a year, regardless of TFS, VSTS, versions, etc.

I cannot see my Product Backlog Item on the board anymore! Is it gone? Are we losing data?

No, we are not losing data, but you need to remember that if you are linking a PBI/User Story as a child to another one the parent won’t be shown in the board, and that is by design.

This is something that dates back a few year – Willy covered it in 2013 but it is an older discussion theme, always worth remembering it though

Help! My PowerShell path in the prompt is gone!

Sat, 14 Jan 2017 11:50:00 +0000

If you follow my speeches you surely know I am a huge fan of posh-git, an extremely handy PowerShell module to display inline repository information.

Today I installed it in a Virtual Machine I am going to use for demos at a conference next month and I noticed something odd at first sight:

Where is my path?!

Thanks to Antonio I realised that maybe it was a good idea to check the documentation. It was indeed…

The whole step 2 section explains how to customise the PowerShell prompt – so it was trivial to restore it to the full path as I like it

Error AADSTS90093 with SonarQube and AAD, why?

Wed, 04 Jan 2017 15:40:00 +0000

It happens. And the reason here is extremely easy and straightforward: if you have any permission on your AAD application for SonarQube which you don’t need you will be denied access

The documentation was updated in June but this error came out recently on an old instance set up before then.

Use the SonarQube Scanner with the new activity for the Team Build

Mon, 19 Dec 2016 10:12:00 +0000

As I mentioned the new SonarSource-maintained activity allows for the SonarQube scanner to be run independently of MSBuild – very useful for repositories containing only JavaScript files for example, where you cannot use the MSBuild-based task because of the lack of a .*proj file.

So all you need to do is to add the relevant task to your build definition:

You only need to configure the required options in the task - it comes with a pre-configured sonar-scanner.properties file so you are ready to go!

You need to create a SonarQube Endpoint like described in the other post, add the typical project key/name/version property triplet and, if you want, you can change the folder containing the source files. Also, if you have your own sonar-scanner.properties ready for use you can supply it in the Advanced pan:

Scenarios where you might want to use this task are where you don’t have a MSBuild-based project system supporting your code, so the other task would not work. Also, it is very handy with heterogeneous projects.

The new connected extension installation experience in TFS 2017

Tue, 13 Dec 2016 11:05:00 +0000

A few months ago I blogged about how the Marketplace takes advantage of the shared TFS and VSTS architecture to provide a good experience to the administrator when it comes to Extensions.

Now the experience goes from good to excellent with TFS 2017!

The installation experience is now completely seamless. From my local TFS Gallery I can browse the Marketplace like I always did:

By clicking that link I am going to be redirected to the Marketplace, but even if I am not logged in as a user I will be logged in as a server:

This is done on the Team Foundation Server instance you are using, if you look at the URL you clicked you can see a serverKey attribute in the query string.

Now I can browse the Marketplace and select whatever I am interested in. Let’s say the Countdown Widget:

Clicking on Install is going to trigger the installation, already pointing at the local TFS Gallery – the extension was already downloaded for you, this happened as soon as you clicked on Install:

That’s it!

It is a great improvement as the experience now no longer requires manual interaction with the server.

This is also an excellent example of a good experience in a context of a Hybrid DevOps Stack, where the Marketplace providing the extensions is part of the stack and it provides the very same service both on-premise and as a service.

What happened to the SonarQube extension?

Thu, 08 Dec 2016 14:45:00 +0000

If you run a SonarQube analysis in your pipeline you might have noticed this:

It is actually the case – the SonarQube extension is being spun off the product and transferred to SonarSource for further development.

This is not bad news, as we already gained the possibility of running the command-line scanner in the Team Build, both on-premise and (that is where it is important!) on the hosted one.

Also, there is a new integration type – a native SonarQube one:

Here you can define your server and use a token for authentication, which is much better than credentials.

Review – Professional C# 6 and .NET Core 1.0

Mon, 28 Nov 2016 16:20:00 +0000

.NET Core brings so many changes, even if you don’t write production code on a daily basis you might want to have a refresh and that’s what I did with Christian Nagel’s book.

It is very well flowing and never too near a knowledge base article – Christian writes very well. The content in there is for Visual Studio 2015, but you can definitely use it with 2017 as well.

I was particularly interested in the .NET Core and ASP.NET Core sections, and I reckon they are really a fresh and clear starting point on the matter. Given we are talking about a printed book it might not be fully updated, but again it is a matter of a few touches here and there. It is worth remembering that it is stuff in continuous evolution, so I would expect it.

But the book definitely isn’t just about .NET Core and ASP.NET Core. It covers extremely well the stack from top to bottom, and I quite enjoyed the What’s new in C# 6.0 section and the recap from C# 1.0 to 6.0 in the first pages. As I said it is about the whole stack, so once you are off the first 450 pages (Part I is all about the language) you can tackle the IDE, the Compiler Platform and more.

I particularly liked how broad the approach was. The Testing section for example mentions not only MSTest but also xUnit, and in both .NET Core and .NET Framework, the Diagnostics section mentions Application Insights, etc. Christian did an amazing job summarising these broad but also specialist topics, and the result is really well-integrated

I am a huge fan of books, and I really enjoy having a well-written reference I can dive into instead of going straight to Google, losing context in the meantime. This is one of these, and I also strongly suggest this book to whoever needs a refresh or is tackling C# and the Microsoft stack with a bit of past experience.

Safely add tasks to an on-premise Build Agent from the vsts-tasks repository

Tue, 22 Nov 2016 12:56:00 +0000

In my last post I uploaded a task from the vsts-tasks GitHub repository to my on-premise Build Agent. How did I know it was going to work in the same way as with VSTS?

First of all you need to check the minimum agent version in the task you are interested in. Let’s take the .NET Core task I used as an example, that task has a minimum version of 1.95:

This means that the task is going to work from version 95 of the closed-source version on Windows. How do I know that?

Before TFS 2017 there were two different agents – a Windows-only, closed-source version and a Xplat, open-source one. The closed-source version was v1.x, the open-source version was v0.x. This version number can be retrieved in the Agent.Version property of your Build Agent:

Now the agents come from a single repository and they are written in .NET Core as a single code base. This version of the agents is marked with v2.x.

So whenever you want to add a task from the tasks repository always check for the minimum agent version required for it. Generally, if you are on the latest version you won’t have problems adding new tasks unless there are breaking changes – and these are really well documented, if any.

Start building ASP.NET Core 1.1 with TFS

Sun, 20 Nov 2016 17:11:00 +0000

In my spare time I am looking at ASP.NET Core – it brings so much change that you can’t really ignore it even if you are not a web developer.

After putting together the first samples (thanks to the help of a book as well, review coming in a few weeks) I wanted to build something in my lab with a TFS build, so totally on-premise and with no connection to the shiny VSTS.

After installing all the prerequisites (Visual Studio 2017 RC is a great starting point, and I added this on top as well) you can easily get up and running by using command-line tools in the build:

But it isn’t really what I wanted… and in Team Foundation Server 2017 there are no OOB tools for .NET Core. Not everything is lost though.

Firstly, install tfx-cli. Not only it works perfectly on-premise as well as with VSTS, but given that TFS now has a Personal Access Token system we can stop using basic authentication with it. Awesome.

Then, we need the nice task VSTS uses. You can get it from here and upload it to your local TFS by using tfx build tasks upload --task-path <your path>. Simple as that.

So you can start using it! Instead of using a .json file as a Project file you can totally point it at a .csproj file – what the task does is nothing but wrapping calls to dotnet.exe so as long as it is updated you are totally fine.

As I am using a basically empty ASP.NET Core application I unchecked the Publish Web Project option in the dotnet publish step – I want total control over the command. Zip Published Projects is fine as it just zips the artifacts.

This is it – I now have a CI build running in…say five minutes?

.NET Core support in the new Team Build with VSTS

Sat, 12 Nov 2016 18:27:00 +0000

Technology on its own is not really helpful IMHO – having an ecosystem really helps. So I noticed that VSTS now supports .NET Core in the Team Build, and obviously I wanted to give it a go

I started by creating a Team Project in VSTS and adding a sample application created with dotnet new –t web to its Git repository:

So it is time to build it:

There is now a Build Definition Template for .NET Core – long are the days when you had only a couple of them…

What this Template does is nothing really fancy – it encapsulated the basic commands from dotnet to tasks. You could have done the same with a command line task yourself, but the key point here is that this is all out-of-the-box now.

I just accepted all the default settings and triggered a new build. It is successful of course…

But again, the point here isn’t about the template itself (which you’ll customise anyway).

The big point is providing support to cutting edge technology, without support and an ecosystem technology alone, regardless of how cool and innovative it is, is pretty much useless.

Don’t just chuck your stuff in VSTS, take advantage of the artifact repository!

Mon, 07 Nov 2016 15:58:00 +0000

If I’d get a penny for any question on this activity I would be a billionaire by today:

It is a waste of time not sorting and creating proper folders for your artifacts – why should you dig into subfolders when you can create the best possible structure?

Firstly, start by splitting any infrastructural definition. There is no point in handling the json files or anything else related to the infrastructure with the packages, binaries and application-specific scripts.

Then try to divide your output into groups. In my case I really like to split between Infrastructure, Packages and Scripts. This is more than enough 99% of the time.

This is way clearer than this:

Without mentioning the folder structure…

That is because the default activity will collect everything you specify in your matching pattern regardless of the folder structure, while the custom activity (where you just add a new one basically, there is nothing really custom there) gets only the final leaf.

Track service usage data in VSTS

Thu, 20 Oct 2016 10:50:00 +0000

Every TFS admin knows about the Operational Intelligence page. It is a very important tool for managing Team Foundation Server, which provides lots of useful information about service usage.

Nothing like that existed for VSTS, up until a few sprints ago. Now if you look at the Account level settings…

The Usage tab is a revamped version of Operational Intelligence for VSTS! Of course you won’t be interested in the server-side jobs as it is a service, but here you can get all the usage audit about a certain user:

It is worth noting that there are rate limits (the Usage column, expressed in Team Services Throughput Units), so you can be throttled or stopped if you are exceeding these – usually with an automated tool or a script. More about this here.

Easy Service Endpoints ACL management in VSTS

Tue, 11 Oct 2016 16:22:00 +0000

It is amazing how quickly VSTS changes and evolves – of course you need to keep up with it as well

This is todays discovery – the new Service Endpoint’s ACL management UI. In the past Service Endpoints were shown pretty much just as a key-value field with an URL, in reality they have two security groups behind the scenes:

Endpoint Administrators
Endpoint Creators

You knew that (didn’t you?), but managing the ACL per-endpoint wasn’t as straightforward as it is today.

The Roles tab in each Endpoint now has a much clearer view of the users’ assignments:

And adding an user is a much better experience now – with an immediate explanation of the role and the associated permissions:

What really strikes me here is the possibility of having the Access inheritance shown immediately – this is a very welcome change for me

A pipeline is not just as vertical fall! Triggers in Visual Studio Release Management

Thu, 06 Oct 2016 17:31:00 +0000

It is great to see people approaching the Pipeline model, but of course the more people adopt it the more we need to go deep into the products we use to get the very best value for us.

An example of this is when you start getting comfortable with pipelines. If you get too comfortable too soon, it is because your pipeline looks like this:

I am not saying it is wrong. There are countless situations where you want or need to keep it that way. What I want to stress is that it isn’t the only way to shape the pipeline!

For example, let’s say you are facing performance issues while deploying because of some reason, or you want to do something else (like initialise the database with real data while deploying your PaaS application, running certain tests while deploying other non-core components of your application, examples are countless here really) – can you do that?

The answer is a strong and definite yes.

Let’s say you want to do this:

“QA – deploy DB” happens first, and then I would like to execute “QA – initialise DB” and “QA – deploy app” in parallel. How? With a proper management of triggers in Visual Studio Release Management

The first environment is automatically triggered by a build, what is interesting is that you can set more than one environment to be triggered by another successful deployment:

Also, you can set an environment to be triggered by all of the previous environments:

So you aren’t forced to use a Niagara Falls pipeline, but something more akin to the estuary of a river

Too long forgotten, the Activity field in TFS

Thu, 29 Sep 2016 09:45:00 +0000

Team Foundation Server is around since 2005, and many features seem to be forgotten despite being in the same place as usual.

If I asked for a dollar/euro/pound every time I was asked this I would be a billionaire as of now:

Can I have a Development Task, Testing Task, Documentation Task Work Item Type in TFS?

You can definitely have such a WIT, but would this make any sense? Excluding any consideration about your methodology (this unfortunately is a question I keep getting regardless of Scrum/Agile/Waterfall/CMMI/etc.), why would you have a different WIT for different flavours of the same?

Usually reasons here vary, but one of the most consistent is this:

I would like to visually understand how the requirement is split and this also makes life easier for team members with different roles in the team.

I mean – the first part is fair enough. But as for the second… it is all about the human rejection of changes

So, in my opinion the best way of tackling this request (I can’t even class it as a problem…) is to use the Activity field which every Work Item has. Simple as that.

Let’s take this for example:

This comes from the backlog, and all the children tasks are…tasks but leveraging the Activity field you can categorise these children tasks:

Needless to say the Activity list can be customised. Once you do that, you might want to apply some styling rules to the task board, leading to something like this:

And as a side-effect, if you use the Remaining Work field as well – as many do, regardless of the methodology as well, given that you might need to report on it – you’ll get a nice breakdown by Activity:

It is worth mentioning that this field is around since at least TFS 2008.

Removing Analysis Services references when moving a TFS deployment

Wed, 28 Sep 2016 15:56:00 +0000

When you need to stand up a testing environment, a DR situation or simply a new instance from existing backups you might want to forget about SSAS altogether and go ahead with just the core Team Foundation Server’s databases – something you can’t do if you use the Application Tier Only option.

The error you will get is a TF400952:

An unexpected error occurred during Analysis Services validation, see logs for details. The component might be damaged or not installed properly. You must exit the Team Foundation Administration Console and install either SQL Server Analysis Services or the SQL Server Client Tools on the application tier to ensure that the Analysis Service object model is present for warehouse processing. Once you have installed the necessary components, open the administration console and re-run the wizard.

If you run into this, it means you did not follow the documentation about how to setup a deployment on a new hardware so back to it, you will run TFSConfig RemapDBs at some point, and that is where you need to pay attention.

If you run TFSConfig RemapDBs without the /continue switch you will just get an error:

Unable to find any compatible SQL Analysis Services database within the specified instance. The host with name ‘TEAM FOUNDATION’ has been assigned a new connection string.

So you are stuck. Instead, if you run it with the /continue switch, you will see the command will be executed on the other databases as well, removing the old SSAS reference.

A pragmatic look at why TFS and VSTS can be customised in a different way

Thu, 22 Sep 2016 09:24:00 +0000

If you paid attention to the latest releases of both TFS and VSTS you can see that the main path where they are diverging is on Process Template Customisation.

And hey presto! I was asked why, and why is it that different from the usual TFS experience. So here is my opinion on the matter

Historically, *no* customisations were allowed for Team Projects hosted on the service. The reason behind this was very pragmatic: being a service, the provider must ensure that any upgrade are not going to break the system for its users, and that includes customisations as well.

Enabling the typical task witadmin.exe can do means they can’t ensure that “the trick you used with Global Lists to show something on a certain field” is going to continue working, with no changes, for each upgrade the service receives without testing it. And of course, the service provider neither can test users’ customisations nor rely on users to test their own customisations according to the service release schedule. It wouldn’t work, and it would cause unnecessary churn and technical debt.

Normally – and this applies to Team Foundation Server as well – you would test your customisations in a sandbox or a test environment. With your own on-premise product you can duplicate the instance (especially with the new pre-production upgrade feature) and start messing around with it. It makes total sense, because hardware is cheap as chips these days and you (or the admins) are responsible for the uptime and availability of the server.

But you can’t have it and you can’t do it on the service, there is no test environment, a service is live by definition! Even with DevOps properly in place there is no way of providing this with the appropriate safeguards.

There is a major difference between providing APIs to extend specific components of your service (usually with a limited scope) and providing a way to easily customise the overall user experience. This difference sometimes is overlooked (unfortunately) when in full-swing with the DevOps infatuation: introducing breaking changes (because you will, everybody does, at some point) on a large portion of the user experience that non-technical users will face is something to are going to regret, because non-technical users are usually more vocal and reactive to UX changes.

UX changes aren’t like custom release task using the VSTS APIs “somehow”, they are all about consistency in the overall experience a user has, and it is critical to understand what is going to happen the second you break something you can see. Can you imagine the mayhem when a non-technical user, who heavily relies on that customisation, is going to get an error and his critical feature isn’t there anymore?

It was the right decision, because the team was missing a way of funneling the customisations in a sanitised and reliable way.

But now they have! And they are doing a great job at enabling these Process Customisation scenarios – usually a big blocker in Enterprise situations.

Simplifying TFS restores with TFSConfig OfflineDetach

Fri, 09 Sep 2016 15:20:00 +0000

Before TFS 2015 Update 3, if you want to restore an instance you need to restore all the collection databases of the instance. This might be an extremely long and time-consuming activity.

Very quietly, Microsoft introduced the OfflineDetach command for TFSConfig. What is that?

It is a new command you can use to restore only a specific collection (and configuration database) so you can simplify the restore operation and save time.

Aside from that, you can also use it to restore non-detached databases (useful for DR).

SonarQube 6.0 and the StyleCop plugin

Thu, 18 Aug 2016 12:30:00 +0000

For one of our projects we use the StyleCop plugin for SonarQube during the analysis. As you can see it was recently deprecated.

I successfully updated the instance used by this product to SonarQube 6.0, when I was told an exception was raised while building:

To make things worse, there are no workarounds or quick fixes to unblock it as you can see from here. The reason behind this is because it isn’t using the .NET Compiler Platform.

Long story short – the plugin is deprecated and it won’t work with SonarQube 6.0. You can either disable the plugin and keep SonarQube 6.0 running or revert back to SonarQube 5.6.1.

SonarQube analysis of Java code with VSTS

Fri, 12 Aug 2016 14:41:00 +0000

As we know, we can use VSTS to build Java code as well as .NET code thanks to the Maven instance provided by the service. It is one of the reasons why we can forget about the build engine with VSTS – it just works.

If I use Maven on VSTS I don’t even need to add a SonarQube task in the Build Definition. All I need to do is to tick the checkbox and point Maven to my SonarQube instance:

This is literally all I have to do. Maven is already configured so I will get my SonarQube analysis in two clicks:

Package Management in TFS15 RC1

Wed, 10 Aug 2016 09:42:00 +0000

If there was a missing feature in TFS 2015, it was the lack of an integrated Package Management solution. Long are these days, the Package Management extension is bundled in TFS 15 RC1!

You just need to install it via your Local Extension Gallery and you are good to go:

You can then create a new feed:

and you are going to get a very nice guidance page to get started:

These are the default permissions:

After that you’ll add the feed as usual in Visual Studio:

so you can start pushing something up there!

Delivery of stuff via NuGet package is more and more frequent these days and you had to rely on a third-party tool like ProGet (on-premises) or MyGet (in the cloud). It is great to have it integrated in Team Foundation Server, extending the ALM platform with out-of-the-box features.

Metatasks in TFS 15 RC1

Tue, 09 Aug 2016 08:25:00 +0000

It isn’t really about TFS 15 RC1 this time, but now the UI is totally out for it so it is very prominent there is a very nice feature I usually see being overlooked when talking about the new build: meta-tasks.

Meta-tasks were added a couple of weeks ago to the service, and they are a very easy way of collating a set of tasks you keep repeating in your build definitions.

For example, let’s say you start a VM and then extract files to it all the times:

You can group this as a meta-task so you can reuse this set of tasks elsewhere:

Once a meta-task is created its configuration is retained, so you can just drop the meta-task in the definition and you are ready to go!

Meta-tasks can be managed in the same hub as Build and Release Definitions…

…and they come with their own set of ACLs, so you can restrict access to them if you want.

The very nice side effect is that once you start creating your meta-tasks and make them available to the team, you can start bringing a new Definition up to speed very quickly because you already have some building blocks to use instead of relying on heavy documentation and long configurations with variables and such.

Easy HTTPS with TFS 15 RC1

Fri, 05 Aug 2016 09:34:00 +0000

There are a number of changes in TFS 15 RC1, and one I really like is the HTTPS configuration.

When you configure the Application Tier you can now select the bindings you want:

Clicking on the dropdown shows all the configurations – HTTP, HTTPS or both:

with the possibility of selecting the certificate straight from the wizard!

You can also change the bindings, the virtual directory and the URL if needed:

It is just a convenience, true, but it is really handy to use instead of doing this

Review – Professional Visual Studio 2015

Thu, 21 Jul 2016 13:14:00 +0000

This is a book I keep reviewing at every release, and for good reason: it is not mainly aimed at seasoned users of Visual Studio but at beginners approaching this IDE for the first time.

This is why you won’t find many changes from 2013 to 2015 – because an IDE doesn’t change as much. But I still recommend it, because of its role as a one size fits all overview of the development stack we use these days.

It is still worth it if you need a reference on your shelve (like I do ), or because it also has good and quick code examples. Eventually I realised one of the biggest improvement is the size of the font from last version’s – it is more readable.

A first look at TFS 15: the new Build Agent

Tue, 12 Jul 2016 14:26:00 +0000

Another big change in TFS 15 Preview is the new Build Agent.

This doesn’t mean there is yet another build server (the new Team Build is here to stay ), the big news here is that the new Agent is cross-platform by default, because it is written in .NET Core!

You can set it up as usual from the main _admin page. Once you add the new Agent, you can select Windows (preview):

You need to add a user as Agent Pool Administrator to run this new agent, as per documentation:

Once you start it, you would be prompted for some configuration settings. It is very easy and similar to the old agent:

All done!

Remember it is a preview, and if you want to start using it that this agent is a replacement for the Node.JS agent. So if you want to keep using TFS 2015 in the meantime do not replace the Windows Agent that comes with it.

As usual, the code for the agent is on GitHub.

A first look at TFS 15: pre-production upgrades

Fri, 08 Jul 2016 16:03:00 +0000

In the last post we saw how to install and configure TFS 15. What about upgrades?

Well, there are some changes…

Starting from the usual wizard, you will select the option for existing databases:

Then you need to point it to the appropriate database server – nothing new here:

Now, this is great. Do you want to run a Production Upgrade or a Pre-Production (testing!) Upgrade?

Let’s go for the latter, as the Production Upgrade is exactly what we have in the current version and there are no changes to that (except for Search).

The next step is pure guidance:

All the TFSConfig commands are going to be executed by the wizard, which means that the headaches from test upgrades and the risk of conflicting with a production instance are now gone!

This is the list of what actually happens at this stage:

There are suggestions, as you can now see:

This is really brillant. All the steps are actually the same as a production upgrade, but with all these added tips and especially with the automated cloning steps at the beginning this new wizard really brings value to the TFS Administrator.

Here is the result:

Note that Search is not automatically installed during an upgrade, because it is an opt-in service and given the deployment size it might lead to performance issues installing it by default.

Upgrading also means the new Work Item Form is disabled – it is another opt-in feature. Once you enable it, you can configure who can request it:

This is really a fantastic job by the TFS team!

A first look at TFS 15: installation

Fri, 08 Jul 2016 13:32:00 +0000

Yesterday Microsoft released Team Foundation Server 15 Preview, and I could not resist installing it as soon as possible

The installation process is the same:

What changed is the configuration process:

The configuration of TFS changed to make it more streamlined in its own wizard, but the first thing I saw was the possibility of configuring a Search Server.

This is because the Code Search feature relies on Elastic Search, and if you have a large deployment it is really suggested to have the Search Server on its own with high performance disks supporting it. More on that later

The TFS configuration now asks for the deployment topology you are using or you are planning to use.

Let’s go ahead with a new deployment, and we will be immediately faced with a choice:

Selecting the Basic scenario the only two things we need to set are the SQL Instance (SQL Express as a default, otherwise an existing SQL Server. Nothing changed from the previous versions):

and Search:

Note that the wizard explicitly suggests using SSDs for Elastic Search. I can tell you, they really help here.

If instead we are going to choose an Advanced scenario…

…we are going to configure the database settings first:

Then the service account and the IIS configuration – nothing changed from previous versions. Search is up next and we already saw the configuration required, then Reporting Services and SharePoint.

Nothing changed for SSRS and SharePoint, but I really like the recommended suggestion (enabled by default! ) of using separate accounts for SSRS and Service Account.

Eventually, change the name of the DefaultCollection if you wish:

Is that it? Not really. During the pre-requisite checks you will surely see this error:

Elastic Search is a Java product, hence a JRE is automatically installed if not found on the machine. Beware, this is always the latest version of the server JRE, so it is slightly different than the usual JRE (it doesn’t feature in the Installed Programs list, it doesn’t have a browser plug-in, etc.).

There is also a new port to open for it, 9200.

Small but noticeable: SSH Service in TFS 2015 Update 3

Tue, 28 Jun 2016 16:01:00 +0000

One of the features introduced in TFS 2015 Update 3 is the backport from VSTS of SSH access for Git repositories.

There is a very nice document on how to use it, so I am not going to look at that, but what is interesting is what happens on the server at upgrade time.

You can decide whether to enable the service or not:

and this will automatically create its firewall rule:

Moreover, you can manage the service from the Administration Console:

A small touch, but much appreciated from an administrative point of view

A simple VSTS-based pipeline for Java Web Applications

Mon, 13 Jun 2016 10:19:00 +0000

I took the plunge last weekend about building a pipeline for a very simple Java application, and it was very, very easy to do so.

The app in question is DeepSpace. It is written in Java and AngularJS, so it looked like it was perfect for my requirement. It is used in the VSTS Java demos, but I didn’t want to go down that route because of the deployment approach.

What I wanted to throw in the mix is Azure Resource Manager of course, I am not going to use FTP and manual credentials from a .publishsettings file anymore! So the first thing I did was to create an ARM template for my website.

What does it take to deploy such an application on VSTS? Well, I would say around ten minutes, tops. I realised Donovan Brown did the same thing, it would have saved me a bit of research!

Start with the build: VSTS has Maven running in the Hosted Build, so there is no setup cost you need to factor in for the build server:

The pom.xml file is kindly provided by DeepSpace, but it would not take long to have one. You can see I am packaging the application (so I would get a .war file, more to come later on the matter) and I am using JaCoCo for Code Coverage – again provided by the Hosted Build.

The next step is publishing the artifacts to VSTS. Nothing really fancy here – just push the .json and .war files.

So, we built our stuff. Now we want to push it to Azure I reckon. Release Management is definitely the right tool for this job.

I am using the Trackyon Advantage task like Donovan because I realised Tomcat is not exposed if you create a Java-based Azure Web Site with ARM, and you can’t change its configuration because it would be running under Program Files, where the user doesn’t have edit permissions.

By the way, if you want to have a look at what happens to your Azure Web Site, at what’s inside and if you want to run a cmd, browse to http://yoursite.scm.azurewebsites.net, where Kodu would provide a great amount of information and you can actually browse and edit (where possible) things.

So, back to RM – I am going to change the format of the .war file to a .zip compatible with MSDeploy so I can reuse the Azure Web App Deployment task and I am not going to fiddle with Tomcat (which means not getting near any credential or custom file modifications, which in turn is very good for automation!). If instead you need/can access Tomcat, use the VSTS extension for this.

I am literally just providing paths here:

Then I am going to deploy my ARM template as usual (it is made of a single Website and Azure App Service at the minute), and I am pushing my Web App as well:

That’s it! I wasn’t expecting it to be that easy – the only place where I stumbled was the war to zip conversion.

What I did was searching on the Marketplace for “war zip”, I had a look and Trackyon Advantage was there among the other five results. I looked at the description and it did what I was searching for. There is literally an extension for everything these days!

Of course the pipeline lacks stages, approvals and all the rest. But this is what I put together in around an hour, so it is a great starting point!

Moving a SonarQube installation to SQL Azure Database

Fri, 10 Jun 2016 10:50:00 +0000

There might be a tons of reasons behind it – you might want to take advantage of SonarQube’s support for SQL Azure Database, and it is totally fair enough.

There was a showstopper in the past if you were on 5.5 – this bug, fixed with the 5.6 release.

So let’s move! But upgrade to 5.6 first, on-premise so you are going to have a clear starting point.

The first thing you need to do is to create a new SQL Azure Database in your subscription. Call it like the one you have on-premise, and use the same collation (tip: remember CS_AS…) for peace of mind.

Then (unless you are using SQL Server 2016) run the SQL Azure Migration Wizard. This tool will do everything on your behalf, and it is going to migrate the database in the cloud.

If you get any connection error here, remember that SQL Azure is locked down for external access – you need to add the IP address for client connectivity to the Azure Firewall:

As you would be using SQL Server Authentication, you also need to create a SQL User for SonarQube. Even if you already used that, the users are not migrated by the tool so it is something to do anyway.

Eventually, change the SonarQube database connection string to your new <azure DB>.database.windows.net in the sonar.properties file:

Done! It is really easy, and if you are moving from a SQL Server Enterprise Edition it is also cheaper.

I updated SonarQube to 5.6 and nothing works any longer, should I panic?

Wed, 08 Jun 2016 09:18:00 +0000

SonarQube 5.6 is the new LTS release, hence there are lots of changes.

The first step where you might panic is when you launch it for the first time, you will find this:

ce is the Compute Engine, a process for data aggregation on the server.

Don’t worry, Process[ce] will eventually go up after you run http://<your SonarQube>/setup and migrate to 5.6.

Then, this at build time:

SonarQube comes with no plugins out-of-the-box! Remember to bring yours from the old installation and update them after the system check..

Getting started with LaunchDarkly and client-side feature flags

Wed, 25 May 2016 08:41:00 +0000

These days it is extremely easy to start using Feature Flags, especially with a service like LaunchDarkly.

In my case, I just wanted to setup a quick demo of client-side feature flags using only plain JavaScript and LaunchDarkly – I am pleased to say it is extremely easy even for a Web 0.9 chap like me! (Yep, I never really got into the Web 2.0 and the WhateverJS frameworks craze of the last few years )

Let’s start with a few assumptions:

I want to use LaunchDarkly to manage my Feature Flags (and there might be many reasons behind this choice)
I want to show features only for authenticated users

I am not going to authenticate users myself so in this case I am going to rely on LaunchDarkly acting as an authentication backend as well. This is totally done on purpose – when a feature is going public then no authentication is required to use it, otherwise a user would be authenticated against LaunchDarkly.

So, I need to create Feature Flags on launchdarkly.com:

Each Feature Flag has a key (feature-* might be a good naming convention), and it is important to set any feature as Available in client-side snippet to access them via JavaScript.

Then add the JavaScript SDK as per the documentation:

Now, all I am doing is extremely easy: starting with the empty ASP.NET Application, I am going to remove the views statically referred by the Controller in the list on the navbar, and I am going to add an id attribute to this list:

Then I am going to add this series of scripts:

The EnableFlags() function is going to retrieve the potentially authenticated user from the Local Storage (I am using it as a mean to save the authenticated user – there is no real backend in this application ), authenticate this user against Launch Darkly, clean the list, and then check if any of my feature flags is turned on for the user. If so, the aforementioned list is dynamically populated.

Bear in mind – this works also for non authenticated users.If a feature is available for them it will show up.

The two other functions are Login() and Logout() – the first sets the user in the local storage and the second one deletes the user. Again, this is not cool or production JavaScript but it is for demo purposes and it works

What happens is very nice: I can start deploying my application only to the users I want to:

Once I am confident with my code, I can rollout the feature to all or a percentage of my anonymous users:

This is just a starting point, the coolest part about LaunchDarkly is that you can integrate it with VSTS so you can rollout a feature at release time:

Use Feature Flags, implement them with either OSS libraries or with Launch Darkly, they make life so easier when it comes to delivering value for your customers!

Simple pipeline with UWP and HockeyApp

Sun, 08 May 2016 17:20:00 +0000

Everybody needs a starting point here and there, so this post would be pretty much about what I did with a very similar situation – a very basic pipeline to push UWP builds to HockeyApp

What I wanted was a carefree, easy way of pushing CI builds to HockeyApp so I could enable manual testing for users. Let me add another requirement to the mix – in my case, we are talking about sideloaded apps, and only for x86 and x64. This doesn’t change the actual result though, we’ll talk about ARM at the end.

This is the pipeline I was talking about.

The first step is a PowerShell script – what it does is to change the value of the last build number in the appxmanifest so that each build will upload a new version of the app to HockeyApp. The service identifies a new build from its build number, so what I did is just changing the revision number with the BuildId of my Build. Simple as that.

Then the build restores the NuGet packages, and builds my app for x86 first and x64 then. The reason why I went down this route is because I wanted to keep things as simple as possible, with a very intuitive tree structure and preparing the folder for the Zip task I used next.

I decided to use a Zip Directories task from fellow MVP Peter Groenewegen. Building a task from scratch wasn’t in the cards because of time constraints in this case, and Peter’s did the job as required.

The task would create a zip file of the App_1.0.0.$(Build.BuildId)_Test folder. This zip file contains the build artifacts I am feeding to VSTS and HockeyApp.

Small shortcut, but this works well basically this name comes out from the AppxBundle process, and the BuildId is there because I changed the appxmanifest file with it so it is nicely available everywhere in my build. This could be extended with a build variable though.

After uploading the symbols, the build uploads the artifacts:

from the folder I used as a destination when building, the build engine searches for the zip file I created previously with the task. It is a Server artifacts, meaning it is stored in VSTS.

Eventually, HockeyApp is fed with this file:

The connection comes from the Service Endpoint you need with HockeyApp. The App ID is the one you’ll find on HockeyApp and the Binary File Path is where the source for the zip file you need to upload is. Simple as that.

In HockeyApp you’ll see the build as soon as the process is over:

The zip files the build uploads contains these files:

which is exactly what you would get from the Create Package wizard in Visual Studio. Running the PowerShell script installs the app on the target system.

I mentioned ARM at the beginning – to add ARM to this pipeline you’ll need to add another build step for ARM, and then uploading the appx file generated by the build.

It is a slightly different process at the moment, and this requires a different provision on HockeyApp as well: the ARM app needs to be separate from the UWP one at the moment so you can upload the build artifact.

Application Insights Live Metrics Stream with ASP.NET 5

Tue, 03 May 2016 10:27:00 +0000

The single feature I deeply loved from the old Visual Studio Online Application Insights (before it was handed over to the Azure Team) was the Developer Dashboard, a real-time overview of how your application was faring.

There is a replacement though: Live Metrics Stream. It is very powerful, way more than the old Developer Dashboard:

The problem is that if you try to configure it with an out-of-the-box ASP.NET 5 Application you will never manage to make it work:

…even if you have the latest Application Insights SDK package installed.

The reason is because not all the features of Application Insights are supported out-of-the-box with ASP.NET 5 – if you run it against .NET Core 5.0.

If you want to integrate LMS in an ASP.NET 5 application, you need to add this code snippet to your startup.cs file and remove dnxcore50 from your project.json file.

I totally expect a full support for all the Application Insights’ features to come soon, but for now if you really need LMS in your application you need to stick with DNX 4.5.1+ as a runtime.

A look at the new Work Item Tracking features in VSTS

Fri, 22 Apr 2016 11:05:00 +0000

I usually don’t do this, but the VSTS teams are overhauling this area at such a pace that makes a knowledge refresh really needed

Aside from the cards layout a few months ago, there are really compelling features added to the platform. It isn’t easy to define what compelling is for WIT, as it is much of user interaction scenarios more than pure technical stuff doing magic, but I find them very, very interesting.

First of all, how many times during a planning meeting you create a Work Item and you then realise you chose the wrong type? Believe it or not, it happens all the times. Now you can just change the type from the UI, easy as that:

Another feature worth mentioning is the possibility of moving a Work Item between Team Projects. There might be a ton of reasons behind this need, I even heard of a Team Project used for support and escalation requests for multiple products.

Anyway, it is just like this, and you can also change the type here:

You can also create a new branch from a Work Item (very handy for feature-based development):

This is a fantastic way of keeping the planning aligned with development, IMHO.

Eventually, you can now follow a Work Item.

This means you’ll get an email whenever this Work Item is updated by other members of the team – I can already see Product Owners’ hands clapping!

Considerations on HockeyApp and exception management strategy for apps

Tue, 12 Apr 2016 12:05:00 +0000

I started to look at HockeyApp recently, and I reckon it is quite an impressive piece of software. Microsoft acquired it in 2014, and now they are pitching it as the solution for Application Monitoring for apps, regardless of the platform, while Application Insights is the APM solution for web application and services.

With that in mind, the first thing we need to know is that we need to join HockeyApp’s Preseason program – it is an early access program (they are quite into hockey over there ). With that you will get access to the UWP support but also to another key feature: custom events.

The thing with HockeyApp is that being an app-centric tool the main usage scenario they developed the product around is when the app crashes in an unmanaged way.

Unmanaged is key here: without Preseason SDK (NuGet package actually) you can only gather crash data at the next application launch. And what if I would like to collect data from exceptions I manage on my own?

That is where Custom Events come around. They are not as descriptive as unmanaged exceptions (HockeyApp collects stack trace data, device information, etc.) but they are a very handy way of keeping track of this important data distribution.

The exception management strategy here becomes two-folded: unhandled exceptions go straight to HockeyApp with all the trimmings, while instead you need to separately log the exception data you need when you manage to catch them, and then send the relevant event to HockeyApp.

In the future I am expecting features to be added from both Application Insights and Xamarin Insights to HockeyApp. The latter two teams merged as of a few weeks ago, and this can only reinforce an already very good platform.

Getting started with Kusto a.k.a. Application Insights Analytics

Sat, 09 Apr 2016 06:43:00 +0000

Last week Brian told us about Kusto, an internal data analytics tools which then became a component of Application Insights.

You can start using it right away, there is nothing to configure. You’ll find an Analytics button in the Application Insights blade on the Azure portal:

There are lots of samples ready to go – let’s take the first one (distribution of response times in the last 24 hours, by response code):

The language is very straightforward – there is also a guide here. The result will be charted at the bottom:

This is another good one – application requests comparison over a 24 hours period:

Data like this is critical for proactive monitoring as well, you can periodically monitor this dashboard and understand where the bottlenecks are in your application.

It is really a great tool!

On the potential of Bash on Windows in a DevOps world

Wed, 30 Mar 2016 20:22:00 +0000

One of the announcements of todays’ //build is the availability of Bash on Windows, thanks to Ubuntu. I share the excitement as well, but focus on individual developers left something behind IMHO: it is a great step ahead for development purposes on development machines, but also from a DevOps perspective.

Let’s put it in this way – if you are developing a cross-platform application, which can run on both Windows and Linux, you now have the potential of a single set of scripts for automation.

You won’t have to maintain two different sets of scripts. You will be targeting both Windows and non-Windows machines, with the same logic, reducing maintenance costs by roughly half and standardising on procedures which would work on both.

I really see it as a game changer in the DevOps world!

SCVMM extension for the new Team Build in action

Mon, 21 Mar 2016 14:48:00 +0000

I mentioned that a few times – I am a real enthusiast when it comes to certain topics, and Lab Management is one of these.

If you installed the SCVMM extension like I did in the last post, then you will find extremely easy to use it in your build process.

You’ll need to create a SCVMM Service Endpoint to allow the tasks to interact with the server:

Once this is done, you will find the new task under the Deploy tasks:

This task has some actions, and it can interact with both a host or a cloud:

There is also a minor bug in this version: if you try to start a VM the task will wait until the end of the specified Wait Time even if the VM is started. THis is going to be fixed soon though.

Advantages of a shared architecture: the TFS/VSTS example

Wed, 09 Mar 2016 14:53:00 +0000

A few months ago I wrote a throwback article for MSDN about VSTS, its journey from “TFS in the cloud” to a full-fledged service, and its evolution.

It is great to see how things evolved, and now it is pretty much the opposite compared to five years ago – they share the same architecture, but for clear reasons VSTS is updated every three weeks compared to the quarterly TFS updates.

A perfect example of this shared architecture is the Extensions Marketplace. Released late last year, the Marketplace is the major vehicle for Extensions deployment and distribution.

It is not only cosmetic extensions and tweaks – even major changes like the SCVMM Integration extension for the new Team Build is distributed that way, which includes VMWare support for Lab Management!

Anyway – back to topic – if you browse to the _gallery page of your TFS 2015 Update 2 RC2 (and RTM when it will be), you will find this:

Which means that extensions built for VSTS can be reused in your on-premise TFS with no changes! For example, let’s take the SCVMM extension I mentioned before:

You can download it, and you are going to be presented with the upload instructions:

It is as easy as they say!

It is literally it. You now need to install the extension, and this is per-collection:

Once you upload the extension, this is available in the gallery exactly like the VSTS’ counterpart:

The great advantage of this architecture choice is that once you deploy something to the cloud, it is much easier to backport it to on-premise and it saves a lot on the maintenance side of the product – once you deploy a fix, the fix is (99% of the time) for both.

Why a TFS pre-release in production?

Tue, 01 Mar 2016 19:01:00 +0000

So, big question: why should I run a pre-release Team Foundation Server update in production? Isn’t it risky? And what about support in case things go wrong?

The biggest reason why you’d want to do that is because you really want to allow your users to enjoy the very latest features of the platform.

For example now we have TFS 2015 Update 2 available as a Release Candidate 1, and you might really want to deploy it because it includes the new Release Management features (for the record, I am ). You can also have reasons related to performance problems, very specific bugs, etc. but usually features are the culprit.

The quality bar is pretty high. I ran many non-RTM releases in production and I hit very few problems or blockers, with live loads and real users’ expectations.

The second best thing about running a go-live pre-release is, oddly enough, support in case things go south. If you have a production issue with a pre-release of TFS, you get some kind of special attentions and for free!

That is because you are providing some very useful feedback from production scenarios, collaborating to increase the overall quality even more.

And eventually – if you upgrade to a pre-release you are still on the official upgrade path, so you can move off it without problems when the RTM is out.

There is a trick though – you must run only go-live releases in production. It might sound obvious, but think about it for a second: it is a pre-release, but if it carries the go-live license it means the quality is high enough to be trusted in production. Different story if we look at CTPs or betas – they often aren’t go-live supported and they are meant only as an evaluation version for future upgrades.

Using custom Quality Profiles with SonarQube and the new Team Build

Wed, 24 Feb 2016 17:29:00 +0000

When you analyse a project with SonarQube you are running the analyser with a predefined set of rules – they are the most commonly used rules, but not the most comprehensive.

This has a lot of sense, because you might not want to end up cluttering the dashboard with tons of information you don’t actually need or that you can’t work on now.

Here is where custom Quality Profiles come into play. For example, I might want a specific build definition to be used for Code Analysis with all the rules enabled.

After creating a new, empty Quality Profile all I need to do is to search for the rules I want and add them to my custom profile. Searching is quite a powerful experience – you can rely on really a lot of criteria, aside from the simple search on the name.

But in this case, the name (CA, which is the code for each Code Analysis rule ran by Visual Studio) will do:

Here you can select which rules you want to go into the profile. If you want all of them, just go for the Bulk Change button on the top right hand side:

You need to type in the name of the profile now:

That’s it!

Now you need to create a new SonarQube project to use this custom quality profile:

From the Administration menu, select Quality Profiles so you can change the default one with your custom profile:

Eventually, configure the new build definition with the same parameters for the SonarQube analyser:

Now you can run the build as usual, and this project will have different results (of course!).

Small but very valuable nuggets about Work Item Tracking in TFS and VSTS

Thu, 11 Feb 2016 13:23:00 +0000

Have you ever noticed this couple of small but very useful features in Team Foundation Server and Visual Studio Team Services?

You can query across projects – think about it, you can create a cross-project (in case you are not using the One Team Project approach) query which can be pinned in the main dashboard. A very minor thing bringing a lot of value to certain roles.

You can compare different fields! I realised this a few days ago (my bad!), and I think it dramatically improves the custom queries’ experience, given that you can build a result based on field comparison.

A new experience with Work Items deletion in VSTS

Sat, 06 Feb 2016 12:28:00 +0000

With Team Foundation Server you can either remove a Work Item by changing its state (leaving it on the backlog then, not really a removal) or permanently destroy it. No middle ground, no real choice if you need to clear the backlog.

With Visual Studio Team Services instead you have this middle ground, with the Recycle Bin.

It is literally that – you can now delete a Work Item via the context menu and it would be gone, moved to the Bin. Pretty much like a file.

Of course it isn’t actually destroyed (only witadmin destroywi can do that, and it needs confirmation for doing that), but it is only hidden from the backlog. All the traceability is retained, which is very handy.

Help, the backlog is gone!

Fri, 22 Jan 2016 21:16:00 +0000

Just beware – if you are migrating stuff from a Team Foundation Server to Visual Studio Team Services, it might happen that despite correctly moving all the Work Items involved in the migration you can’t see the backlog as you would expect.

But don’t panic, this doesn’t mean data is lost, it just means that data is not showing up – a completely different matter. That is confirmed by creating some custom queries asking for all of a certain type of Work Item Type (all PBIs for example): you would get all the Work Items you are looking for.

So, what is the problem here? Look at the areas: if you do not allow areas to automatically link sub-areas, your backlog is not going to show what you want.

Lots of panic for nothing

Where are TFS and VSTS heading?

Thu, 14 Jan 2016 19:37:00 +0000

This week Microsoft made published an update to the Team Foundation Server and Visual Studio Team Services roadmap, and it looks very promising.

As we already know, TFS and VSTS are an ever evolving platform. This is true for both on-premise with regular updates delivered roughly every quarter and for the cloud service, where the new features are always delivered first.

There are already a few set of features slated for TFS vNext – this is neither a surprise nor a defeat admission, the amount of work for such features is very big – think at the listed improvements for Work Item Tracking alone.

But it isn’t everything for vNext – there is a lot coming in Update 2 and Update 3 as well. The Lab Management overhaul is one of these features, coming in Update 2, like extensions on-premise and the new Release Management.

Keep an eye on that page for TFS and VSTS, because it is updated on a regular basis and it is a great source of information for planning well in advance.

A cryptic story around Git, VSTS and Azure Active Directory

Wed, 06 Jan 2016 13:33:00 +0000

This is a short and easy tip with an interesting background.

If you try to push stuff to a Git repository hosted in a VSTS account, where this account is backed by Azure Active Directory and you are not logged on with the relevant credentials, you are going to get a quite cryptic error:

The Output window is not quite helpful either:

What is going on here? The reason, as I stated, is simple – I wasn’t using the right credentials. But the problem is that Visual Studio is not warning me, while instead the command line would just ask for the credentials.
One of these things you need to just know, I assume

I updated Release Management and my builds fail: now what?

Mon, 14 Dec 2015 21:52:00 +0000

This is a quick but worth tip to remember.
If you upgrade Release Management, you always need to update the Client. Up to this, fair enough.

But you are going to start getting errors like “The account running the TFS build service needs to be added as a system user in the Release Management Server” in your build.

What you might be missing is that in order to allow communication between the two you also need to at least open the client, and if you keep getting errors you might also want to remove and re-add the Release Management URL into it.

This operation will recreate the authentication tokens and you can use VSRM again.

Things to remember when you work with Azure and the new Team Build

Sun, 06 Dec 2015 16:09:00 +0000

Azure is an amazing piece of technology – its capabilities are immense and there is always something new to learn and use for solving our problems.

It is quite a while I am spending time on it, together with the new Team Build and a few other bits and pieces all around. I thought about summarising these little issues you might face as well, so you should save some time

First of all, please remember this: if you don’t have a build task OOB, and you don’t want to write your own, you can still use PowerShell! Never forget how powerful it is, because it can be used in literally thousands of ways.

If you are working with TFS 2015 RTM you won’t have the new build tasks bundled with the Update 1 or support for Service Principals, but don’t worry – you can achieve the same results with a bit of PowerShell.

For example, bearing in mind that creating a Service Principal for your Azure Active Directory is as easy as the first part (steps 1, 2 and 3) of this blog post, this is all you need to do in a PowerShell script to use the Service Principal for authentication:

At the moment support for Service Principals is limited to Azure Resource Manager, so for deploying any components you might want you still need to rely on the old certificate-based authentication.

The issue here is that the combobox in the build task for Web App Deployment (VSTS or TFS 2015.1) doesn’t specify anything like that. What I suggest is to follow the following approach and add the Azure subscription with both authentications:

So you would get a subscription in the comboboxes anyway, regardless of the authentication method you chose.

Eventually, bear in mind that the new build agents expose capabilities – so if you want a specific agent with Azure PowerShell installed you would need to specify AzurePS as a demand in the build definition.

What’s happened to the Visual Studio installer?

Thu, 03 Dec 2015 21:37:00 +0000

Well, they sorted it out! The Visual Studio 2015 installer is now componentised:

It is now very straightforward to understand, especially for upgrades. This is true also for the third party components like the Android development stuff.

How was that possible, given the monolithic ISO that Visual Studio was? Let’s have a look at the packages:

And then there is a file for the external, downloadable components. It is the feed.xml file, this is an extract:

Kudos to the team!

Endpoints in a Team Project: what shall I do with them?

Thu, 26 Nov 2015 20:54:00 +0000

If you roam around a TFS/VSTS Team Project Administration page you will surely come across the Services tab:

What am I supposed to do with these? Why is there “Endpoints” and “XAML Build Services”?

Let’s start with the first question – in VSTS or TFS you can connect external services to interact with various features, like Build or Release Management.

Azure is a great example in that regard, because you can link a subscription to a Team Project for deployment purposes, once you do so all the combobox related to Azure Deployment (ARM, Web App, Cloud Services) will be automatically populated.

But there is not only Azure:

The Generic Service Endpoint enables third party services like Perfecto to integrate with the platform – you need to provide a URL and some authentication.

Subversion? Yes, also SVN is supported on VSTS and TFS 2015.1. It is something new – the Java ALM team delivered this integration to enable Subversion as a repository for build definition. Kudos to them!

Jenkins is for the build engine as well, so you can use it in the OOB build tasks.

Now onto the second question – the separation between XAML Build Services and other Endpoints is because the former handles services in a different way.

But as it is more and more becoming something old and deprecated, only Azure is available for these. Moreover, the XAML Build Service Azure integration doesn’t support Service Principals out of the box so you need to customise it should you use them.

Shopping in the Marketplace with Visual Studio Team Services

Fri, 20 Nov 2015 10:54:00 +0000

With the rename, ~~Visual Studio Online~~ Visual Studio Team Services introduces the Marketplace for its extensions.

It is a very welcome addition to the platform, as it enables scenarios of customisation in a very easy way.

Once you are logged in your VSTS account, you can browse and choose an extension:

Each extension has its own page with all the details, and it is the entrypoint for the installation:

The amazing thing is that it is all on your service – clicking Install brings you to an installation page, where you need to select the VSTS account you want to install the extension in:

That’s it! Once installed, you can go back to your account and start using it!

It is transparent for the users, which will just see the extension working as a feature of VSTS. All the extensions are managed at account (hence Collection) level.

Upgrading SonarQube to 5.2, my notes

Tue, 17 Nov 2015 22:12:00 +0000

Today I updated our production instance of SonarQube to the eagerly awaited version 5.2.

It is such an important release because it finally embraces a full client-server paradigm (whereas the runners had to talk straight to the database before of that), it introduces support for Integrated Authentication for its database, and more.

The documentation rightly suggests to not copy across the old sonar.properties file but to carefully cross-check the settings you are modifying – it is a very wise suggestion, as the strings are now different (albeit they look similar at first sight).

The JDBC driver for SQL Server is now different, it doesn’t use jTDS anymore so keep an eye on your connection string. And there is also support for SQL Azure, which is a very nice touch if you host SonarQube on it. If you want to run Integrated Security you have to fiddle a bit, downloading the SQL JDBC driver and manually copying it in the appropriate folder. Everything is documented though.

SonarSource introduced a wizard (a first, I think, in the Java world…) for the upgrade – but beware, the wizard will start only if all the connection and configuration strings are set in the right way.

All the ~~runners~~ scanners must be updated, pointing straight to the SonarQube instance instead of the database, and eventually another very minor issue – if you have a custom image (the top left one) in your SonarQube instance you need to reset it and set a width, as it isn’t preserved.

Small touches I like in the TFS 2015 Update 1 Upgrade Wizard

Fri, 30 Oct 2015 16:52:00 +0000

Microsoft is always working towards improving the user experience of its products, and Team Foundation Server is no exception to this rule.

There are two bits I really liked in the Upgrade Wizard of 2015.1: the new Build Agent configuration and the Upgrade Progress monitoring page.

For the first, now it is totally clear what are the paths a Build Agent (referred to the new Team Build, of course) uses:

For the second, I can now monitor not only the step of my upgrade but also the elapsed time, and if there is any problem going forward.

At the bottom there is a very handy link to the logs, and if something happens during the upgrade, the Issues link brings you straight to the relevant log:

Again, they are all small touches, but very relevant regardless of how often you use them

Dashboards in Team Foundation Server 2015 Update 1

Tue, 13 Oct 2015 19:45:00 +0000

Another great new feature in TFS 2015.1 is the introduction of a real dashboard instead of a pre-built welcome page.

This is an example:

This is an upgraded Team Project by the way. There are a few out-of-the box widgets, but is there a Definition of Done widget? Of course not

You now have the flexibility of creating your own widgets, including a markdown widget:

Everything is customisable – this is my markdown example:

You can also create multiple dashboards – this is extremely handy if you have different teams with different focus across the same Team Project:

Each dashboard can be totally different, they are independent with each other.

Eventually, there is a new Welcome page experience. This is Markdown as well:

and there is one page for each repository by default, as it is based off the readme.md file created into each repo.

This is really a very welcome addition to the platform, as it enables even more collaboration and information’s sharing scenarios as ever.

TFVC and Git in the same Team Project: a revolution

Sat, 10 Oct 2015 09:04:00 +0000

TFS 2015 Update 1 is literally hot off the press, and I am already on it as the changelog is massive!

The #1 priority to me was to have a look at Git and TFVC in the same Team Project. This is a really important milestone for the future.

It means the Version Control storage become agnostic – you can have Git repositories in existing TFVC-based Team Projects (a legacy evolution if you want), but also the other way round, a TFVC storage into a Git-based Team Project.

The experience is as easy as it, you just need to go to the _admin page and under the Version Control tab you can manage that:

If you already have TFVC configured in your Team Projects, you can’t add another repository of the same type of course:

Why should I add a TFVC repository if I already use Git? Well, migrations, large file storage are two examples.

You need to run Visual Studio 2015 Update 1 (currently in CTP1) to fully access these new repositories - which obviously highlights that you have both the Version Control systems in place.

The next thing I will look at (across the weekend ) are the dashboards!

Problem solved! Git-LFS and VSO

Fri, 02 Oct 2015 22:25:00 +0000

One of the problems you might face with Git is the performance hit when you start storing binaries into the Version Control.

It is actually by design – Git takes content snapshots at every commit, and it can’t handle deltas on binary files like on text files.

Fair enough, it has lots of other pros (and cons too), but the inability of storing binaries in an easy and non-disruptive way hampered the need for a shared tool in an heterogeneous development teams. If you have people working on the UI of your applications and you want them to version the .psd files they use, you can’t use Git.

Well, you couldn’t. GitHub developed Git Large File Storage for sorting this issue, but it wasn’t by default and eventually you would need to pay for usage (over 1GB quota of free space and bandwidth). It isn’t a out-of-the-box solution.

But yesterday Microsoft announced Git-LFS support on VSO, and it is a game changer to me.

Firstly, it is enabled by default on all the Visual Studio Online’s Git repositories. What you need to do is to install the Git-LFS extension, and nothing else.

Then, it is free for unlimited storage, so you don’t have to worry about limits, quotas and usage. It’s there, use it (if it makes sense, obviously).

Eventually, it will be included in Team Foundation Server 2015 Update 1, meaning that you will get exactly the same experience on-premise.

That’s marvellous, really. It solves the aforementioned issue in an effortless and easy way, making Git even more approachable.

Personal Access Tokens in Visual Studio Online

Mon, 28 Sep 2015 15:21:00 +0000

When you try to access some services in Visual Studio Online, you might need to enter your Alternate Credentials. Think about Git, for example.

This approach works, no questions about it. But in terms of security it isn’t the best choice. It isn’t granular at all and credentials have no expiry date.

But Visual Studio Online also provides Personal Access Tokens, to fix this inconvenience. A Personal Access Token offers better granularity and expiration management:

And how to use it? You need to safely store it (you can’t access them after the creation, by design), and then you can use the string in place of the password when asked.
The username in that case can be whatever, it is just not used.

Why shall I split the columns in the Kanban Board?

Tue, 15 Sep 2015 10:22:00 +0000

A very interesting discussion came out at the SmartDevsUG meeting last night about the Kanban Split Columns in TFS and VSO. What is the real rationale behind it in a real world project? Why should I have a Resolved column split in Doing and Done, for example?

Without taking into consideration the Kanban principles behind this tool, I have an easier explanation. If you step back from the technical stuff for a moment and you think about the business side of it, it is pretty clear.

For example, you are working on a customer hotfix for your product – the code is done, the fix is tested thoroughly and you are technically done. But you aren’t completely done – did you deliver the hotfix to the customer? Or from a different perspective, is it billed? Until this hurdle isn’t cleared, you are in a Resolved-Done situation.

Reading the TFS update logs

Thu, 10 Sep 2015 12:47:00 +0000

Did you ever read a TFS update log? If not, you should do it.

Once you do anything on the TFS databases, all the operations are logged, obviously. You can reach these logs from the Administration Console:

The amount of data in there is really helpful – for example, each Stored Procedure used by the installer is detailed, giving you an idea of what happens to your databases during each update:

And you also get a recap of how long it took with each individual timing:

That is interesting enough if everything works, but what about when something fails?

Well, that’s even better, because if you experience an error whatsoever, you will get a detailed exception stacktrace in the logs:

This gives you a real actionable insight before touching anything or raising the phone to call CSS.

Draft Builds in the new Team Build

Fri, 28 Aug 2015 15:21:00 +0000

With the new Team Build you have the possibility of working on Build Definitions in an asynchronous fashion, without impacting other team members or wasting time cloning the existing build.

For example, you might want to add some tasks to an existing Build Definition – you can then Save as a draft..

You are actually creating a clone of the existing Build Definition with the new steps you added. You can even run it!

All the builds you run with this definition are marked with a .DRAFT in the name:

This is not different compared to any other build – it is just not affecting the existing published builds:

Then once you save it everything is merged with the original definition, with no further effort.

Quickly change the TFS Integration Platform settings

Tue, 25 Aug 2015 12:56:00 +0000

You installed the TFS Integration Platform, and now you want to move your database. Or you want to change the temporary folder used during the migrations.

Shall you waste time reinstalling it?

No, what you need to do is to modify some strings in the MigrationToolServers.config file:

Pre-upgrading a large Team Project Collection to TFS 2015

Thu, 13 Aug 2015 10:57:00 +0000

TFS 2015 is out and we all rush upgrading our Team Project Collections!

But if you have a collection bigger than 1TB you should stand back and read some documentation before that. This page in particular explains what you should do if you want to upgrade such a huge collection.

The reason for using TfsPreUpgrade is very simple – you don’t want your users stuck for days while you upgrade Team Foundation Server. So the tool is going to partially upgrade the schema while the server is still available, so the actual upgrade (the one done by the installer) takes no longer than two days, which means a weekend, which also means no perceivable service interruptions.

You can run TfsPreUpgrade from whatever machine you like. In my testing environment I am using at the moment I am running it from a plain Virtual Machine which is going to be used by the Application Tier, but it has nothing installed yet. You basically need access to SQL Server, and that’s it.

First thing, run it with the Estimate switch. It will give you an idea of the time and space needed for the upgrade:

To give some context, this is data for a 2TB Collection. A few hiccups while running the Run switch might happen, especially with a temporary test environment:

but you can just relaunch TfsPreUpgrade and it would start again from the same failed point after a quick check. It is smart enough to not further expand your databases if you don’t need it:

Once it is done your offline upgrade will be much faster, because these operations were carried in advance!

Change the Release Management URL when the console is stuck

Tue, 04 Aug 2015 10:37:00 +0000

Quick one, but helpful IMHO. After updating Release Management Server or Client you might experience this:

and then you would be stuck – you can’t change the Release Management Server URL.

The quick and dirty solution would be changing the URL in the Microsoft.TeamFoundation.Release.Data.dll.config file.

A better solution is to run this command line tool, which basically automates the former. In the worst scenario, reinstall the Client and it would prompt asking for a Release Management Server URL.

Team Project rename: is it that easy?

Mon, 27 Jul 2015 10:25:00 +0000

Renaming a Team Project was the most asked feature for Team Foundation Server since 2005, with over six thousands votes on it. Microsoft finally delivered that feature in April, in Visual Studio Online first and then in Team Foundation Server 2015.

Why did it take so long?

Team Foundation Server relies on a set of SQL Server databases, with a quite…complex schema. It wasn’t just about detecting a certain name and replacing it, it is all about GUIDs and the likes. A lot of work was done on the architecture, and more of it client-side.

Client-side? Yes.

When you rename a Team Project in either Visual Studio Online or Team Foundation Server, what happens among the operations is that also you are also creating a redirect from the old Team Project to the same, renamed one.

Take a look:

this Foo Team Project has some work in it:

a query with an explicit value in it (Foo instead of the @Project macro):

and of course some code.

You can then rename it:

and what you’ll need to do is to care about code mappings (workspaces or remotes, this would be best handled by a client update – 2015, 2013.5 or 2012.5). Code is migrated, Builds are migrated, and all the Work Item Tracking migration is completely effortless.

So you say yes, and the Team Project is renamed. Teams with ‘Foo’ in their name are migrated too:

Areas and iterations are migrated too, as expected:

Even the explicit query is migrated!

So what happens if you go straight to Foo?

This:

This doesn’t mean you are going to lose the possibility of using the former name – if you will reuse it, you would just lose the URL redirect but all the renamed artefacts would be kept as-is..

There are a couple of things you need to manually address after this. As mentioned above, you need to sort out the Workspaces or the Git Remotes, depending on the Version Control System you are using.

If you are using a BDT Build Definition with Lab Management, you need to refresh the Build Definition by running the wizard again so it can be properly linked again with the right Team Project. This is actually a workaround which will be solved by the new TFS 2015 Legacy Build Controller, but if you need to use older Controllers that’s how to sort it out.

On-premises, run a ProcessWarehouse job and a ProcessAnalysisDatabase job as soon as possible, so you will avoid any stale data in SSRS and the Excel Services in SharePoint would be already updated with the current names. The jobs would run anyway in the time interval you set, but this will avoid any temporary inconsistency in the reporting data.

Eventually, clear the SharePoint cache and run a SharePoint timer job so the Excel Services are up and running on the right values.

TFS and HTTP status 417

Fri, 17 Jul 2015 09:44:00 +0000

Panic today – a guy couldn’t connect to Team Foundation Server with a weird “The request failed with HTTP status 417: Expectation failed.”

What did it happen? I never saw such a HTTP status code!

A bit of investigation explained the reason for it – the proxy he is using doesn’t support the expect100Continue behaviour, dropping the connection.

The guy used a proxy server indeed and he did not check the “Bypass proxy server for local addresses” checkbox. After checking that, he was able to connect to Team Foundation Server like everybody else.

It is also worth mentioning that this can impact also components like the Extension Manager, and you can bypass that setting by adding a node in the devenv.exe.config file - <servicePointManager expect100Continue="false"/>

How to configure SCVMM-based Lab Management for selected Team Projects

Mon, 13 Jul 2015 14:59:00 +0000

Not all the Team Projects we have in the company might need to get Lab Management, and we pretty much know about the need of locking down certain resources.

So if you want to enable SCVMM-based Lab Management you need to configure the Library Share and the Host Group on a case-by-case basis instead of dropping them all in, by un-checking the Auto-Provisioning checkbox here:

Then you need to run TFSLabConfig TPLibraryShare /add and TPHostGroup /add to enable the single Team Project.

How easy is to use a Symbol Server with Team Build vNext?

Fri, 03 Jul 2015 11:37:00 +0000

Answer: it is extremely easy!

A Symbol Server is a very important piece of infrastructure every development team should have. It enables someone debugging (with the aid of an IntelliTrace file for example) problems happened in production, relating them with the right version of the code deployed.

To use a Symbol Server with the new Team Build, you need to have a local build machine, and a file share. That’s it.

Download the agent, and expand it in a folder – say C:\agent:

Once done, launch ConfigureAgent.ps1

A command line wizard will start. Most of the times you only need to enter the relevant Visual Studio Online account or Team Foundation Server URL. If you want to run it as a service the default would be with LOCAL SERVICE, but you can obviously use whatever account you need.

Now you have a Build Agent on the Default Pool:

Create a build, and you will have the Index Sources & Publish Symbols activity already part of it. Then you only need to enter the file share you want to use for the Symbols Server, and launch a new Build.

What is this all about? If you browse the file share you will have all your PDBs indexed.

Then you can hook it to Visual Studio, so whenever you open an IntelliTrace file, or whatever other dump you can get from a production crash, it will point to the right version referred in the source of the crash itself.

Scrum meets the pool – swimlanes in VSO’s backlog board

Tue, 23 Jun 2015 14:29:00 +0000

With the update of June 3rd VSO got a new and very useful feature in the Backlog Board: swimlanes.

What does that mean? It means you can have this situation:

This allows for an even finer time and resources management, for example. It mostly impacts prioritisation, something that happens with critical bugs stopping a production system. Keep in mind that a swimlane configured as above should be used very sparingly.

It could be even more creative:

You might be selling a product which, from time to time, has customer’s personalisations, which you need to schedule with the product itself. This is another way of using the swimlanes.

It is a tool which increases the flexibility a lot – but remember that it is just an aid, it doesn’t work as a given. Your process must be already resilient to this, and the tools is only there to help.

Beware of the Package Location in VSRM!

Tue, 16 Jun 2015 13:11:00 +0000

I am working on a few scenarios using VSRM and DSC, and something funny happened. Picking a build up for release, I noticed this:

Localhost? I am pretty sure I didn’t enter localhost anywhere in VSRM!

And I was right – there was no localhost to be found in my pipeline configuration. But this just caused problems deploying to a different workgroup target server, due to the lack of a proper DNS infrastructure.

The culprit here is the XAML Build I was using, its Drop Location was configured with \\localhost because it is an AIO demo box, and as there is no such name resolution facility VSRM cannot access my source server from the target.

To fix this you’d just need to change the Drop Location of the build.

A note on reusing your custom fields

Wed, 03 Jun 2015 10:17:00 +0000

When you customise your Work Item Types you often start with a lone custom Field, and then you forget about it for a while.

But what happens when you need to add the same field to another WIT? The first thing you are naturally inclined to do is to add a new one, with the same name and reporting design but with a different Reference Name (because maybe you attended one of my sessions on TFS Administration and you then discover you should mark your custom Reference Names in a significant matter :-) ).

The result?

How can I reuse my existing field then? The easiest way is to create the custom Field in the second Work Item Type with exactly the same properties, including the Reference Name. So TFS will correctly use the same Field and your experience is going to be consistent.

A design consideration: SQL Server AlwaysOn Availability Mode for TFS

Sun, 17 May 2015 21:05:00 +0000

There are a few bits of any Team Foundation Server deployment which are either taken for granted, or completely ignored. One of them is:

Why shall I choose a Synchronous-Commit Availability Mode for the TFS Data Tier using SQL Server AlwaysOn?

If you are running an AlwaysOn Availability Group, you should know that you have a choice on how to write your Transaction Log – hence your database integrity. My suggestion is to run Team Foundation Server’s data tier in a Synchronous-Commit Availability Mode.

The reason is very simple: TFS relies heavily on the Transaction Log, and it is the only way to guarantee a point-in-time recovery. Moreover, if you run AlwaysOn you cannot have any database in the Availability Group set without the Full recovery mode.

So you must use the Transaction Log, and it is critical for the Team Foundation Server recovery – using the Synchronous-Commit mode ensures that each Secondary Replica in your Availability Group has an updated copy of the Transaction Log, synchronised at the same time as the Primary Replica, for immediate failover and service continuity.

You will face a really minor increase in the RTO (a few seconds, generally) and a performance loss, but we are talking about something you won’t be able to realise in general usage, and you are ensuring your service has an excellent reliability.

A design consideration: Reporting Services on the Application Tier

Fri, 08 May 2015 11:17:00 +0000

There are a few bits of any Team Foundation Server deployment which are either taken for granted, or completely ignored. One of them is:

Why shall I install SQL Server Reporting Services on the Application Tier?

Fair question, if you are not considering installing it on a separate box – a different approach, usually not as common as the former.

The idea is to centralise all the client-originated HTTP traffic on a single endpoint. The endpoint of course can be a cluster address where you have multiple SSRS servers and Application Tiers, but the concept is the same. Centralise your traffic, possibly using DNS names. The documentation suggest that too:

so that the data tier is exactly that: the storage for Team Foundation Server’s (and related, if you want) databases.

Beware: it is not wrong to install it on the data tier (it is actually supported since Team Foundation Server 2008), but it is a matter of best practices.

TF30170 errors and the TFS Cache

Thu, 07 May 2015 10:36:00 +0000

Weird things happen, like this:

“An item with the same key has already been added.” How?!

Nothing catastrophic actually – it is just a matter of clearing the cache. This happened because this instance of Team Foundation Server was restored as part of a Disaster Recovery exercise, and its ID was not changed.

So, in order to solve this (and other similar TF30170 errors) just look at the logs – if you find that explanation message in one of the exceptions, or similar (like “cannot add LinkTypes relationship”) then I would suggest to clear the Team Foundation Cache:

<OSDrive>:\Users\<youruser>\AppData\Local\Microsoft\Team Foundation\

There are some folders in there, each containing a Cache folder. Empty those Cache folders, and try again. If there is nothing actually wrong underneath the Team Project would be created without problems.

A couple of remarks: it happens that the Team Project would be actually allocated on your target server even if the creation fails (it won’t be accessible and it is shown as Deleting). In this scenario it is pretty common that Visual Studio launches part of the temporary Team Project deletion but it would fail because it is not pointing at the right server GUID – open the TFS Admin Console and relaunch a manual deletion on the temporary Team Project.

Eventually, this might happen because you are not marking your Transaction Logs backups, so you restored some of the database out of the right order. Please use the TFS Backup Tool, or if you can’t, mark the transactions so you won’t hit that again.

Visual Studio ALM at //BUILD – recap

Mon, 04 May 2015 19:22:00 +0000

Tons of stuff at this year’s //BUILD! It was really exciting and there were a lot of news about Windows 10, Edge and the ecosystem.

But this post is going to be about all that’s been announced for Visual Studio ALM. Brace yourselves, it is quite long :)

Visual Studio Code
An evolution of Codename Monaco, this Electron-based app enables a great editing experience on not only Windows, but also MacOS and Linux. It is free and downloadable from here.
SonarQube and Team Foundation Server integration
I already started working on it, this is a joint release from SonarSource and Microsoft to enable a deep integration between SonarQube and Team Foundation Server so we can have the same parity as Java for Technical Debt Analysis with SonarQube. It is a very well welcomed effort, I can’t wait to bring it into several projects I have in mind.
Visual Studio Release Management 2015
Some light was shed on VSRM at //BUILD, we now know that much of the goodness of the new Release Management (with full support to Chef, Puppet and Team Build vNext) is going to be released with Team Foundation Server 2015 Update 1 or during the Summer on Visual Studio Online.
CodeLens
This is quite big – CodeLens is integrated in Visual Studio Professional 2015! Plus, there are new indicators like Combined Authors, When Last Changed and support for every file type.
Cloud Load Test
I can now define from where my traffic is going to be generated, so I can generate a better profile of my simulated usage.
REST API and Service Hooks for Team Foundation Server 2015
As Visual Studio Online and Team Foundation Server share the same codebase, we are going to get both REST APIs and Service Hooks!
Extensions for Visual Studio Online
Based on the existing REST APIs, Visual Studio Online is going to boast a brand new extension capability.
Application Insights in Public Preview
Oh yes, Application Insights is in Public Preview now! And with additional capabilities – a better Java support, iOS and Android devices as first-class citizens, a new shiny integration in Eclipse and XCode!
IntelliTest
Do you remember Smart Unit Tests? Well, the name wasn’t as good as it seemed to be, so it is now IntelliTest (like IntelliSense and IntelliTrace). There are two additional features now – Parametrized Unit Tests (you can define your data properties for the generated tests) and a Create Unit Tests menu.
Developer Assistant
The Developer Assistant gets full access to the enormous amount of code hosted on GitHub! 21 millions of examples to browse.
GitHub extension as a Managed Hosting Provider
GitHub enters Visual Studio as a new Managed Hosting Provider, so you can have a seamless integration inside the IDE like if it is Visual Studio Online or Team Foundation Server.
Improved Git branches and history views
The integration of Git into Visual Studio proceeds, the branching view and the history view get lots of love, making it way easier to use on a daily basis.
Team Projects Rename
Ten years later, we finally get Team Project rename in Team Foundation Server! This is a fantastic milestone (as it required lots of rework under the covers)!
Improved Build vNext preview
Team Build preview is more aligned to the latest bits running on Visual Studio Online, it is a lot more stable and there are several new features in the web UI.

There is actually more, this is just a quick feature recap. For instance I purposely left out the Agile Boards improvements in Team Foundation Server, as I believe it is pretty clear it is being ported from Visual Studio Online to the on-premise product. In case you still have doubts, have a look at the Visual Studio Online and Team Foundation Server Feature Timeline.

Eventually, it is worth having a look at the Release Notes for TFS and Visual Studio.

SQ-TFS.Scripts, automation scripts for SonarQube and TFS

Wed, 29 Apr 2015 19:26:00 +0000

This is my second take at open-sourcing something!

Yesterday I read about the fantastic joint release from Microsoft and SonarSource for an integration between SonarQube and Team Foundation Server. As a quality-first advocate, I was immediately on it and yesterday I set up the environment based on the 45 pages long document.

It is very well done - like all the Visual Studio ALM Rangers’ content! – but I thought about automating it, so it could be easily replicated in a lab.

You’ll still need to manually setup SQL Server (for now) and install Java. They are pretty basic – they follow the walkthrough, without any diversion, except for the InstallSonarRunner script, where I introduced a v12 and v14 script for respectively TFS 2013 and TFS 2015, both using the legacy XAML Team Build.

You can find them here. Please let me know if you run into issues, I would look into further automation so it can even more seamless than now.

Remember, remember, remember…to close the TFS Administration Console!

Mon, 20 Apr 2015 15:35:00 +0000

That was fun :) While working with TFSConfig I hit this error on a TFS Farm’s Application Tier…

Oh, right, I have it open. I run the command again after closing the console and I get the same error.

The lesson? Close the TFS Admin Console on all the Application Tiers of your TFS Farm, otherwise TFSConfig will detect it as open and return an error.

How to schedule a TFS Integration Platform session

Wed, 08 Apr 2015 10:52:00 +0000

You might need to schedule your TFS Integration Platform session at a certain time, and the TFS Integration UI doesn’t expose such an information.

Not all is lost though, the UI relies on a Console Application:

As you can see, you can feed it with a Configuration File. It would be a breeze then scheduling a task with the Windows Task Scheduler, to run whenever it is convenient for you.

Why ‘Doing’ and ‘Done’ in the Kanban board?

Fri, 27 Mar 2015 16:47:00 +0000

Visual Studio Online introduced this feature a few weeks ago, and then I’ve been asked…

Why is the split column inside another column?

That is absolutely a fair question.

Kanban rotates around the concept of Capacity Flow, minimizing turnover and cycle time.

The so called ‘Kanban Boards’ – the Backlog Boards in reality - in Visual Studio Online take this principles as foundational when it is time to present an aggregated view of the development situation. Capacity is immutable by definition, unless there is an external intervention.

Also note that the we are not looking at the same stuff. The Sprint Backlog Board will boast the true States of my involved Work Items, which are then mapped to the Kanban Boards’ Metastates. Here is an example:

This is my Process Template. But my board looks like this:

What happens is that regardless of the Metastate (between New and Approved) the actual Work Item State is still Proposed. A Metastate is basically a way of determining how it is visualised, given that all the constraints are valid of course.

But back to the original question – does it make sense?
It does, indeed. These feature might seem just cosmetic stuff, but they actually contribute a lot in keeping the teams’ meeting lean and the procedures simple and effective.

Even if a PBI is Approved, it still might have work on it. Hence separating the Doing/Done phases makes it way easier for the Product Owner to understand the actual pace of the team. This works very well with the Definition of Done on the board, which I covered on this post.

Definition of Done on the Boards – how, and my thoughts on why

Tue, 17 Mar 2015 16:38:00 +0000

Last week Microsoft rolled on the latest Visual Studio Online sprint deployment, and among all the new features there is the possibility of adding a visualisation of the Definition of Done in the Kanban Board.

How? It’s very easy, you click on Customize columns in the board, and you add the DoD for each column you want to add it to:

Easy as chips. But where is the real value of this (very welcomed) feature? Why is it that good for me?

Step back from your role a minute, and think. What is the Definition of Done?

The DoD is usually a clear and concise list of requirements that a software Increment must adhere to for the team to call it complete.

That said, the Boards are meant for team’s consumption, hence reporting the DoD in a shared, neutral tool is an amazing way of pushing the concept of the Definition of Done itself. It is under everybody’s eyes and it doesn’t leave space for interpretation, so it enforces how to properly relate to it.

A lap around the new Application Insights

Mon, 09 Mar 2015 16:21:00 +0000

I really like Application Insights – it is no mystery, just look at how many posts I wrote on it – and the last time I purposely played with it was around 2013.3 last September, with the 2.0 version approaching the release and a complete under the hood rewrite to fit into Microsoft Azure.

Well, a lot changed in the last six months…let’s start from scratch: we have a Web Site running, we want to add Application Insights as the production monitoring solution.

You are running on Azure, so the request monitoring is implemented out-of-the-box. No configuration, no code changes – it is offered as part of the Azure infrastructure. If we want to monitor the actual end-user usage, we need to add a bit of JavaScript to your pages:

Doing this will enable the usage monitoring. You are going to notice how fast and sleek Application Insights is now compared to the old Visual Studio Online implementation, it is a matter of a couple of minutes at worst and you are going to look at your freshly fetched data:

Obviously you can dig into this data – it is a monitoring platform after all!

The Diagnostic search is very cool because it is a pre-filtered, context-based series of charting which enables troubleshooting and diagnostic scenarios with a couple of clicks. For instance here I can access the details of a page’s status in a certain session:

subsequently, I might want to see the telemetry for the whole session:

so looking at what this user did, in case I am inspecting a suspect behaviour on a bug report:

The other option is on a timeframe, so looking at the ten minutes interval around the event I scoped my search on:

Moving on to the health and performance monitoring, you need the Application Insights Telemetry, a two-click operation in Visual Studio which is going to lead to a new NuGet package installed in my solution:

So I can enabled scenarios like this - I have a troublesome page here:

I can dig into the Metrics Explorer, and look at the stats – each event is reportable and will boast a number of properties you can use to investigate.

If you want to log custom events, it is a matter of using the same appInsights object created by the existing snippet and model what you need to log. For example, I might want to log an event with two properties, a string and an integer:

and out-of-the-box I would get support for sorting and aggregating my custom properties in the charts:

To be fair, I really like the workflow provided by the Azure Portal’s blades. Let’s say I have an exception:

For each level I dig into, a blade opens, so I can easily keep track of the workflow I am following. Very good use for all these 16:9 screens around :)

The Properties blade is the same for each event, so I can retrieve the relevant telemetry in any case. My users for example behaved like this:

It’s a matter of seconds understanding where this issue is.

But what if you want more logs? Mostly important, more logs at lower levels? Here they are:

Eventually, you get live streaming of the Application and Web Server Logs:

This is actually quite verbose because I set it so, but you have four options to choose from…

The new Application Insights is more promising than ever – I am seriously impressed by the effort the team spent on it, Application Insights now feels very solid and it sports even more data than before, without mentioning how integrated it is with Azure.

Why can’t I output the result of git log from a PowerShell script?

Thu, 05 Mar 2015 12:54:00 +0000

Git log is a special command, it uses a pager and it seems the PowerShell ISE hangs when you run into that kind of commands. If you try creating a script relying on running git log in whatever form, you won’t get anything.

The workaround is not the very best, but it does the trick:

$logcommand = "git --no-pager log ... [> file.ext if needed]"
Invoke-Expression $log

Other commands like git diff are not affected by this. This made me lose quite a bit of time this morning…but I am happy to be unblocked now.

A first look at Team Foundation Server 2015

Wed, 25 Feb 2015 21:22:00 +0000

A few days ago Microsoft released a first CTP of Team Foundation Server 2015, together with another one for Visual Studio 2015. Whoo!
I was particularly curious about Team Foundation Server, as the preferred way of evaluating new features is Visual Studio Online. Keep in mind what Brian said: “More than anything it was a forcing function for us to practice getting ready to ship TFS 2015”, meaning I’d expect other TFS 2015 CTPs soon. Moreover, don’t forget many of the Visual Studio Online features had been brought into TFS 2013 Updates, so it isn’t like 2008 any longer.
It is the beginning of a new wave. The TFS 2015 wave! It is quite of a change, I reckon, but based on my experience it works pretty well. I manage a gigantic TFS deployment with all the trimmings, and being on the Update Train is perceived as extremely valuable by both my colleagues in Operations and my users. So expect sizeable features to show up after RTM.
Before looking at the actual features, a word on the installation process itself. It didn’t change a lot, but there are a couple of tidbits worth mentioning.

You can now configure a Basic Server (TFS Basic as we knew it) or a Full Server. The Full Server makes it clear that the new Build is a new core service:
SharePoint Foundation doesn’t ship in the box anymore, hence the 370MB ISO size. You can still integrate with an existing SharePoint deployment of course:
So let’s start with what’s in the CTP1:

Extensibility and integration
Agile tooling improvements
Licensing changes
Build.vNext

Extensibility means you now have the whole set of REST APIs which were available in Visual Studio Online only, together with the Service Hooks. This is very interesting for the whole lot of in-house applications you might have, plus a out-of-the-box integration facility with the supported 3rd party services.
Oh, integration…I think this screenshot says it all:

Do you want to integrate with a Jenkins build server? A couple of clicks, and you are in!
On the Agile tooling improvements it is basically lots of what we already saw on Visual Studio Online with all the reliability improvements we cannot see because they are behind the scenes.
To be honest, I read quite a few comments busting the Product Team’s work because there aren’t hundreds of new eye-popping features in this CTP, and I cannot agree with them. It is a CTP1, to be used as a shipping test for the team, it isn’t feature-complete or go-live supported. Why all this mess? They used to be called alphas, and I still remember the excitement when the first virtual machine containing an alpha of Visual Studio 2010 (codename Rosario at the time) came out, with really few features inside a Visual Studio Team System 2008 IDE, and everybody was excited about it. On my side, I’d rather appreciate what we can have to learn and share feedback, instead of complaining…
Anyway – back to the features :)
The licensing changes are all about the Stakeholder Access Level, extending lots of the Standard features to the basic, CAL-less tier. It is amazing because it enables a true involvement by the stakeholders themselves, without being too limited by the lack of a CAL.
Eventually, Build.vNext – it is a new Team Build concept, based on scalable agents instead of rigid matching between controllers and agents. But what matters most is that the workflow is now easier, clearer, and cross-platform.

Does this mean the old XAML-based build is going away? Absolutely not, everything works as it does today, but this is now the way forward for the future. With Build.vNext, you won’t have a dedicated Build Controller setup any longer. You can have it, but it would be the Legacy Build Service we saw in the installation as a separated, optional step to do – aka XAML-based Team Build.

PowerShell DSC in legacy pipelines, or with no pipeline at all

Thu, 12 Feb 2015 22:09:00 +0000

It is true that PowerShell DSC is the newest kid on the block, but it is also true that we can integrate it in legacy pipelines, or where we have no clear pipeline whatsoever.

How? Pretty easy – even if there is DSC in the name, we are still talking about PowerShell, hence who can stop us from invoking a legacy script or even a command?

For example, think about where you have a script which stops IIS, copies the new content and then the scripts restarts IIS, using iisreset and xcopy. Not best practice at all, but it is broadly used. You can replace it with this:

The Invoke-Command cmdlet is a standard PowerShell one, it has nothing to do with DSC. But embedded into a DSC script it can make a functional step into the DSC script itself.

Even better, do you have a preparation script which prepares the environment? You can use Invoke-Command with the –FilePath switch, pointing at your script, as part of the DSC script.

What are .tfignore files?

Wed, 11 Feb 2015 14:06:00 +0000

I was talking with Gian Maria this morning about the need of excluding some files from the Version Control, with both TFVC and Git. With Git (and the .gitignore file) you can specify rules for it, but what about the TFVC?

Typically you have two options, a check-in policy or a .tfignore file. What is the latter?

It is a file which specifies some rules about the allowed and disallowed files in the Team Foundation Version Control. You need to create it in your Workspace folder, and you can specify rules like these. Yep, pretty much like the Git counterpart.

Of course it isn’t like a check-in policy, but it provides a good way of enabling basic rules on the allowed files in your TFVC. It is very helpful anyway when you have large teams, it enables a quick distribution of a standard set of policies without too much mess around the startup.

The hidden gem of Microsoft Test Manager: tcm.exe

Tue, 03 Feb 2015 13:41:00 +0000

Can you clone a specific Test Suite into an existing Test Plan? Not really.

Shall you resort to Excel, getting – in this scenario – an half-baked result? No, either.

And what if you want to work with test artifacts in a script?

You should use tcm.exe instead! By design, MTM doesn’t expose all the possible capabilities, for a matter of User Experience. As it is a tool aimed mainly at testers, too many options might be confusing for the user. But that does not mean that a scenario like cloning Test Suites (not the whole Test Plan or the single Test Case) is impossible or barely possible by using tools not really fit for it - tcm.exe fills this gap.

What you’ll need to do is just calling tcm suites:

You can get the Suite ID from MTM. Even if you are cloning from/to the root of the Test Plan, it is still a Test Suite hence you have a Suite ID:

You can also override fields, and clone stuff across Team Projects. It is pretty handy.

But it isn’t over, as it has other capabilities:

I find very, very useful the possibility of running specific tests from the command-line (tcm run) and, very helpful in case of migrations and integrations, downloading the XML mapping of Bugs, resolutiontype and failuretype with tcm fieldmapping.

My first approach with open-source: TFSThemeUploader

Thu, 29 Jan 2015 10:37:00 +0000

To be fair, I’ve never been involved in open-source very much. I mean, personally. Moreover, I have always been quite shy of my stuff, as nowadays I mostly write scripts and no longer full-fledged production applications.

But anyway I decided to give it a go. So please, do not shoot the pianist, alright? :)

TFSThemeUploader is a simple PowerShell script aimed at automating the scenario described in this MSDN article. I’ve always thought it is quite tedious to manually complete, as it requires a bit of fiddling around XML and command-line tools. There is absolutely nothing wrong with it, but when you need to perform the same actions for more than one or two projects it isn’t very…compelling – hence the script.

I might expand it actually, to make it a bit more user-friendly and to expand the possible scenarios, I have a couple of ideas. But for the meantime, it is a good start I think.

Continuous-Integration-as-Infrastructure and Git Flow

Sat, 17 Jan 2015 13:46:00 +0000

This came out at Friday’s meeting of the London ALM User Group – can I set up an infrastructure CI build for my whole Git project, configured with Git Flow?

I think Git Flow is a great piece of tool for non-enthusiasts or anyway people with limited interest in understanding Git. It creates a naming convention skeleton for your branching strategy, and using SourceTree you can let this kind of users work on their stuff with limited supervision.

So, thinking on it – can Team Build help? Of course it can!

If you select the appropriate Include statement for the branches you’d like in the Build Definition, it is literally one click away:

Doing so you are telling the Team Build to run a build (CI in this case) on the feature/* branch, where of course the star is a wildcard. Every branch you are going to create will benefit from it without any effort.

So you commit whatever you need, and the CI is already working for all you wish - given the mapping.

Visual Studio Release Management as a Service – a quickstart

Wed, 14 Jan 2015 20:07:00 +0000

Let’s face it – cloud computing is utterly cool (pay-as-you-use service, near 100% availability, no infrastructure costs) but it is not for everyone. Even myself, I keep maintaining my own lab even if I use cloud services, both for learning and production purposes. But there are tools where the infrastructure and setup costs are not for everyone – think about Exchange.

IMHO Visual Studio Release Management is amazing, but its infrastructure and setup/maintenance cost might not be for every taste. That’s why having it as a Service in Visual Studio makes it even better!

If you install the Release Management Client on your machine, you just need to connect to Visual Studio Online instead of an on-premise server:

After you log on with your MSA, you will notice the URL automatically changing – that is VSRMaaS!

This is the only setting you have to care about. All the rest is managed by Visual Studio Online.

So, how can you use it? There are a couple of limits, for now. It is a beta, and it supports only vNext environments. A vNext environment is an agent-less deployment environment, which leverages PowerShell DSC. Eventually, it can be both in the cloud or on-premise. After that, it’s all the usual VSRM stuff…

The caveat is that you need to use DSC – hence no pre-existing activities but just your own scripts:

These scripts are going to feed the Release Pipeline, exactly like the agent-based VSRM deploys.

If you need a jumpstart though, use the integrated menu in Visual Studio: it is going to create stages, components and templates on your’s behalf!

Useful SQL queries for the TFS Administrator

Thu, 08 Jan 2015 11:37:00 +0000

Right, right – I know:

I would actually replace can with will, but people might think I am too harsh. Remember – the TFS databases cannot be modified by nobody but Microsoft, otherwise you won’t get support, you might experience unknown (and untested!) issues and mostly important – you would lose any upgrade path as the schemas are checked by the TFS installer.

Anyway I won’t be talking about modifying the databases, while instead I wanted to share some useful queries I found during my almost ten years experience with Team Foundation Server.

SQL Server is a deterministic system, but sometimes it doesn’t seem to be. For instance, AlwaysOn is synchronising some data after you messed up with a Team Project Collection used for testing purposes, and despite it might look stuck it is actually doing something.

The AlwaysOn Dashboard doesn’t show anything but a Synchronizing status, so how can I say so?

Run this query:

SELECT dmv_2.login_name AS Invoker,
dmv_1.session_id AS SPID,
command as 'Instruction Type',
a.text AS Query,
start_time AS 'Initiated at',
percent_complete AS Percentage,
dateadd(second,estimated_completion_time/1000, getdate()) AS ETA
FROM sys.dm_exec_requests dmv_1
CROSS APPLY sys.dm_exec_sql_text(dmv_1.sql_handle) a
INNER JOIN sys.dm_exec_sessions dmv_2
ON dmv_1.session_id = dmv_2.session_id

This is what you’ll get:

Excluding the line where I am the Invoker – of course – I can see all the activity at 11:08am:

NT AUTHORITY\SYSTEM running sp_server_diagnostics
The TFS and SQL service account in this testing environment running an INSERT query – that is AlwaysOn!

That query leverages SQL Server’s DMVs, and it is very handy for checking all the things happening in the Database Engine.

Another one is about Transaction Log files – what about their physical status?

SELECT Name,
database_id,
log_reuse_wait,
log_reuse_wait_desc
FROM sys.databases

Querying sys.databases can give you the status of your Transaction Log files. I needed that because I was running some extreme tests in borderline conditions, hence I had to monitor their status. Sys.databases is very handy for other information as well.

Eventually, as Grant suggests (and he is always right!), DBCC CHECKDB regularly is a must. And please, have a test server around so you can compare all the behaviours, if any.

Troubleshoot a Team Project deletion

Mon, 22 Dec 2014 11:32:00 +0000

A colleague of mines once said “it’s never a stupid question if you don’t know the answer.” So that post might sound stupid, but I had people asking for it hence…there it goes!

You might need to delete a Team Project, and it is a matter of seconds, isn’t it?

It is not always the case, unfortunately. But you can do a lot to understand what goes south. Just using the TFS Admin Console.

Firstly, when you have a DeleteProject job running, you can actually check what it is doing. It is not very intuitive, but if you double-click it, you can access this:

Ok, the job fails. You know what? If you double-click the failed job you can get a very detailed log:

and digging down there you will surely find the reason why the job fails:

That specific case, well…just size your testing environment accordingly, ok? :)

Reducing Technical Debt with Smart Unit Tests

Tue, 09 Dec 2014 11:53:00 +0000

One of the reasons behind Technical Debt is the lack of appropriate test suites around a certain feature. Especially when implementing something new, tests are critical in shaping a robust and quality solution. Often, if you have something in the works and you are not strictly operating TDD, tests are behind where they should be.

Visual Studio 2015 introduced Smart Unit Tests, which are nothing but the former MSR Pex project, rebranded and productised. What Pex/a Smart Unit Test does is to analyse your code and create a basic suite of unit tests to test the basic, border scenarios. Here is an example:

Right click on the method, Smart Unit Tests…

and here is the result:

Of course – this is a really, really basic scenario. What is interesting IMHO is how it is doing it behind the scenes:

as mentioned, it is a full-fledged Unit Test. Very basic, but still a good starting point, saving time while in the works. And if you save it, the Smart Unit Test engine is automatically going to create a new Test Project with the aforementioned tests contained in there. Again, it is not meant to remain as-is (“Sum748” is not a great test name for instance…) but it is still better IMHO than doing everything on my own.

Let’s make things a bit harder now:

That is very crappy code in small scale. No exception management at all, just the plain and down-to-the-bone feature, potentially in development. I can ear people screaming, but it happens extremely often in every organisation. This is the output of Smart Unit Test in this scenario:

It seems I need to spend some time on handling DivideByZeroExceptions and OverflowExceptions, to begin with…

Lab Management and Environments – what to remember

Mon, 01 Dec 2014 16:45:00 +0000

Lab Management’s SCVMM environments are nothing more than a bunch of Virtual Machines running somewhere in a datacentre. Really. I do not understand the reluctancy (almost fear!) when I mention it.

Let’s start with Network Isolation. Network Isolation is an extremely handy feature, allowing a side-by-side deployment of multiple instances of an environment with the same properties (machine name, IP addresses, basically everything which should not be duplicated in a network). It is very cool.

And guess what, there is a clear, step-by-step guide on how to create a Domain Controller VM to be used as a template for a Network Isolated Environment. Basically once you installed the ADDS you need to clean the DNS.

Once you have the VMs ready, I would suggest to compose some environments to be reused without searching for the VM every time. To then enable the Network Isolation, you need to check this checkbox in the Advanced tab of the Wizard:

That is all you need to do. SCVMM will then add a secondary Network Card to the VM to enable this feature, but it is nothing you should worry about.

Also remember that unless you set auto-provisioning, your VMs won’t be automatically shared among the Team Projects in a Collection. You can import them from the library you used to store the template anyway.

One last thing to remember on the VM Templates – always remember to enable the File and Printers Sharing firewall exception, otherwise the deployment would fail, and you won’t be able to connect to the VMs via the MTM Environment Viewer for instance.

If you want an all-in-one reference, have a look at this appendix from Testing for Continuous Delivery with Visual Studio 2012 – even if it is on the older version everything is still relevant. The whole book is actually on the matter, so I suggest to have a look at it.

Another misunderstood topic seems to be Test Settings. We all have seen the fantastic demos with screen and audio recording, but then all of a sudden you cannot set it up in your lab.

To enable that feature, you need to install the Desktop Experience Feature on your Windows Server VMs:

and then select the Screen and Voice Recorder diagnostic data adapter from the Test Setting you want to use:

Each DDA can be configured to better suit the usage you want, in this case just bear in mind that you are storing big binary files inside the Team Project Collection database, so its size might increase very quickly if you use it a lot. Moreover, there is a number of useful settings you might use:

You can copy specific files (not tied to the Version Control or the build output) to the VMs, run pre and post-test execution scripts, or even force 32 or 64-bit execution in case you need it:

Unfortunately the number of resources here is not immense – MSDN is extremely useful as usual, together with the aforementioned eBook, the Visual Studio ALM Rangers Lab Management Guide and the Pro Team Foundation Server 2013 book.

But again, this is not rocket science so you should be good with them.

How to configure Visual Studio Team Lab Management 2013, once and for all

Mon, 17 Nov 2014 21:44:00 +0000

Every time I go at a conference/user group and Lab Management is mentioned I hear someone saying “Lab Management? I never understood how it sticks together…” “Wow, it must be an adventure to set it up!” and so on…

Well, after all Visual Studio Team Lab Management (yes, fancy name) is not rocket science at all! It is just a clever mix of many different components, each doing a different thing, to enable the “Virtual Test Fabric” scenario. Nothing more, nothing less.

To begin with, you would need System Center Virtual Machine Manager (2012 R2), at least one Hyper-V host, Team Foundation Server (2013.4 in this case), a Build Controller and a Test Controller.

Assuming SCVMM installed and configured (how: install SQL Server Database Engine, install SCVMM pointing at it, add an Hyper-V host), you need to install the SCVMM Console on the Team Foundation Server Application Tier. Now you can configure Lab Management!

You just need to enter your SCVMM FQDN:

and – if you wish to use it – an IP Block and a DNS Suffix for your Network Isolated machines:

This is the core, infrastructure configuration. You are going to see that something is missing though…

You just configured the infrastructure for the whole Lab Management deployment, what’s missing is the configuration for each Team Project Collection you want to enable.

The two settings you need are:

A Library Share (a normal SMB share) containing the SCVMM templates used by VSTLM to create your VMs
A Host Group (it’s actually optional, as SCVMM creates a default “All Hosts” Host Group, which in your case is enough as we are assuming you are starting with one Hyper-V host server)

As mentioned, the Auto Provision flag enables all the Team Projects contained into your Collection.

Now the only missing piece is a Test Controller to bind to Lab Management. In fact, if you launch Test Manager and try to create a new Environment, it would complain:

So, let’s install the Test Controller and configure it:

If you need it, configure a Lab Service Account as well. This is helpful in cases where you need to resort to Shadow Accounts (or you can’t add the Service Account to the Local Administrators group), but let’s keep it simple and skip it for now. Just keep that in mind:

That’s all! This is the whole Lab Management configuration! Is it still rocket science? In another post we are going to look at the environments’ configurations and at some useful tips from the real world.

Why can’t I delete a Test Plan with MTM and TFS 2013 Update 3?

Sun, 16 Nov 2014 21:55:00 +0000

Do you want to delete a Test Plan from MTM? Fair enough.

Unfortunately the documentation is a bit outdated here – a quick Google to find this, and it is about Visual Studio 2010. It would work – but only if you are connected to a Team Foundation Server without Update 3.

If instead you are running 2013.3+, you would be greeted with a message saying … “Deleting a test plan is not supported for current version of Team Foundation Server. Use witadmin tool 'destroywi' command to destroy test plan work item.”

It is not a bug, but it is by design instead - it is the only downside of the conversion to Work Item Types of the Test Suites and Test Plans.

Basically prior to Team Foundation Server 2013.3 they were ‘special artifacts’, meaning you wouldn’t be able to treat them like Work Items – including advanced querying, charting, etc.

The Update 3 converted the whole thing to plain Work Item Types, but this means you no longer get the special feature of deleting it via MTM, instead you should run witadmin destroywi from the Developer Command Line – which is the only way of doing so. That is because deleting a Work Item is not really something that happens every day, and if done in the wrong way (for example, truncating relationships in linked Work Items) it could lead to issues with the Work Item Store.

Visual Studio Lab Management and Auto Provisioning

Wed, 05 Nov 2014 13:09:00 +0000

Despite it is very handy, the Auto Provisioning feature of Lab Management can become a trouble pretty quickly. If enabled, every Team Project will be authorised to deploy VMs in the VSTLM hosts, a situation which – 99% of the times – becomes unmanageable.

It’s not a TFS problem, and it depends on how the users are used to work. But if your deployment is used (as it should be, to be fair) and considered ‘as a service’, then IMHO you need to limit the scope a little bit, otherwise your Hyper-V servers are going be clogged like Beijing at the rush hour…or the M25.

There is a pretty quick fix for this though – after you grant the permissions to the specific Team Project to use Lab Management, you need to use two TFSLabConfig (and not TFSConfig Lab) commands: tfslabconfig TPHostGroup and tfslabconfig TPLibraryShare.

After that, you are ready to go!

Impact of the new Visual Studio Online European Region

Tue, 28 Oct 2014 15:07:00 +0000

With the latest update Microsoft addressed one of the most repeated requests about Visual Studio Online. It isn’t a specific feature or capability, but it is a EU-hosted region for it!

Up to yesterday, you did not have any choice on where your VSO data is hosted - the VSO tenants were only in Chicago, San Antonio and West Virginia.

It wasn’t a matter of performance or latency – I personally never had heavy problems unless a service-wide problem arised – but it was all about governance. If you are a EU-based company or anyway you have operations in the EU, you know data protection it is a pretty important matter.

We are not talking about Microsoft snooping into your source code and looking at your intellectual property, not at all, but depending on what you work on you might have strict regulatory policies to apply. In detail, if you have EU operations (which means even a single server running in the EU), the EU Data Protection Directive applies, and it is stricter than the US counterside, especially on when data leaves the EU.

Visual Studio Online is covered by the Safe Harbor since I recall its existence, a bilateral agreement between the US Federal Trade Commission and the European Commission providing reciprocal protection to personal and sensible data, but for certain businesses or countries it was just not enough. Germany is a good example, where its privacy laws are way stricter than the general EU umbrella.

Eventually, if you store your data – whatever it is – on a US hosted service, your data could be inspected by the US Law Enforcement agencies under the PATRIOT Act.

So, introducing a EU-hosted region (in Amsterdam, for completeness) means a lot in terms of governance, as all of your intellectual property hosted there is subject to the EU DPD as such, and that’s all.

What you will be lacking today is Application Insights – but it would reach the EU VSO in time for its General Availability.

Can I host multiple Git repositories in Team Foundation Server?

Thu, 23 Oct 2014 08:41:00 +0000

Of course you can!

I am in the middle of a migration project, and the team I am helping with has several Git repositories (converted from other version control systems) to upload to their Team Project.

It isn’t extremely intuitive – you need to open the Control Panel for your Team Project (https://yourserver.domain.tld/yourcollection/yourteamproject/_admin/_versioncontrol)

and from there you can create a new repository.

That’s all!

When you’ll navigate to the newly created Git repository you will get the Getting Started page as well, which is very helpful for first-time users.

Again on the logs: are errors in the logs going to stop an upgrade?

Thu, 16 Oct 2014 15:37:00 +0000

A quick but interesting question came out this week: “if I see an error in the Event Viewer of the Application Tier, is it going to break a TFS upgrade?”

Generally speaking – no. The errors you see in the Event Viewer are client-side logs reported to the server. You might see an error on a client not able to connect, another one because of a non-existent user or value in the Work Item query, or more critically an error because you cannot contact your data tier.

It is the data tier which contains all the meat. All the data is stored over there and, if you look at the Configuration logs after an upgrade, the big show is there.

Of course there is a correlation between the data tier’s schema and the application tier version – everything is handled by the same binaries.

Logs, logs, logs…

Thu, 09 Oct 2014 08:57:00 +0000

Team Foundation Server is by no means an easy product – especially with large deployments. One of the most important aids in the daily maintenance is taking care of the logs, which are very descriptive.

Apart from the usual suspects (IIS, SharePoint, SQL Server, SCVMM) inside the Event Viewer you are going to find all the logs related to the TFS Services – these logs are especially invaluable when it’s time to troubleshoot a client issue, because they will contain exactly the error the user experienced plus many information about his environment (in particular which client triggered the error).

One example is an error like this:

“TF10158: The user or group name <group> contains unsupported characters, is empty, or too long" Once it is logged inside the Event Viewer I am going to get the error itself, plus who (the user account) and from which client (Visual Studio, a browser, MSTest, MTM, etc…) experienced that – guess what happens if you receive a question on such a group

But what about setup or update logs? They are elsewhere – you are going to find the link into the TFS Administration Console.

What is amazing is their verbosity – did you ever try opening one of them?

They are pretty self-explanative, and when it comes to a version update you will find detailed information about every step the setup does. This explains many things…for instance, did you know that the 2013.3 update which enabled Test Suites and Test Plans customisation has much of its foundations in the Update 2 bits?

Hitting the limit on a Local Workspace

Tue, 23 Sep 2014 09:21:00 +0000

Everybody remember the introduction of the local workspaces in 2012, enabling offline scenarios with Team Foundation Server. But did you know they have a limit on the number of files prior to performance degradation?

This limit is 100000 elements.

TF401190: The local workspace temp_WS;User has 248536 items in it, which exceeds the recommended limit of 100000 items. To improve performance, either reduce the number of items in the workspace, or convert the workspace to a server workspace.

There it is. It’s not a bug, but it is a design choice by the Team Foundation Server team.

Local workspaces work leveraging the content of the hidden $tf folder, which tracks all the changes for a file (deltas) from check-out to check-in. That’s how you get features like Candidate Changes. The side effect is that despite the source copy is compressed, it is still a copy, hence you have a physically bigger workspace.

The workarounds in this case is to use a server workspace (easy) or to split the huge, monolithic workspace into several smaller workspace so you won’t hit the issue. This could be harder than just using a server workspace, but with a bit of planning it is absolutely feasible.

This post by Philip Kelley is extremely enlightening, as it is a deep comparison between local and server workspaces. Right there he explains the differences, and how they are implemented (the PendChange permission, the +R bit, etc.).

Application Insights: what’s going on?

Sat, 20 Sep 2014 06:39:00 +0000

I guess it has been a little overlooked, but there is a lot of moving around Application Insights…
The biggest thing is that with Visual Studio 2013 Update 3, Application Insights is moving towards version 2.0. It’s not a mere version change…

Application Insights is being moved to Microsoft Azure, and 2.0 is the first version of it. The move is not complete yet, so the 1.3.2 version – running on Visual Studio Online – works, and it contains all the current feature set, but bear in mind that they are “rebuilding it from the ground up as part of Microsoft Azure”.
If you want to understand which version you are running, just check the ApplicationInsights.config file: if it contains a schemaVersion, then you are using the 2.0 release.
The Azure version lacks several features at the moment (Windows Store and Windows Phone apps monitoring, different APIs) and there are a couple of architectural changes, most notably the agent-free performance monitoring.
But it does not mean you are losing anything: it was in preview on VSO, it is in preview on Azure, and you can use both. If your application or service is configured to send data to the 1.3.2 version, this is not changing as there is no automatic upgrade.
There is only one thing to consider: if you remove the 2.0 package and you restore the 1.3.2 one, you cannot return to the 2.0 without repairing the Visual Studio installation.

Again, again and again on the backups

Thu, 11 Sep 2014 20:58:00 +0000

This is a topic which I find coming back every now and then: backups of the Team Foundation Server.

Team Foundation Server is a SQL Server-based product – hence most of the backups’ work happens there. Full, Copy Only, Differential, Transaction Log: choose your flavour, as long as you are confident it’s good.

IMHO it is a good practice to keep things simple: a daily Full Backup with hourly Transaction Logs Backups provide a good level of protection without involving the (IMHO) complicated Differential Backups.

If you can, use the OOB tool: it is mature enough to do its job without too many worries. But if you happen to need a manual backup, there are a couple of information to keep in mind…

In order to be supported by the Microsoft CSS your backups must be synchronized – no exceptions. The safest way of doing that, as it required manual interaction with the TFS databases, is to follow this MSDN walkthrough. I introduced a slight modification as I manage a big deployment which uses SQL Server AlwaysOn, which is just the verification of the preferred backup instance, but the core steps are the same.

The reason behind that is pretty simple: the Team Project Collection databases refer to objects (like IDs, or identities) stored in the TFS_Configuration database. If you restore a Team Project Collection database which contains something not aligned with the Configuration DB, it is going to end badly…

And remember to test the restore – otherwise you do not have a backup

TFS Transaction Marking on SQL Server AlwaysOn Data Tier

Thu, 28 Aug 2014 09:31:00 +0000

If you need to manually backup the Team Foundation Server – you might have several reasons for not using the OOB tool – you need to follow this walkthrough on MSDN.

What I’d like to share is a small script you might use while you have to backup your Team Foundation Server running on an AlwaysOn-backed Data Tier.

I created a hourly job in both nodes, running one minute prior to the Transaction Log Backup job, as it follows:

In our case, we backup the Primary Replica, so before initiating the transaction I check for the preferred Replica. If it is 1, it’s the primary, otherwise it is the secondary (2) or it is resolving (0), both cases where my job cannot run.

It might be a little bit overzealous, because if you run the very same job on a non-preferred Replica (the secondary in our case) you are going to get an execution error stating the databases are read-only, but better safe than sorry!

Why is my Incremental Analysis Database Sync going on forever?

Wed, 20 Aug 2014 14:32:00 +0000

Sometimes it happens...

And that’s just because I stopped it. Why does it happen?

The reason is pretty easy: if the job is running, but you have a network problem – an outage, like it happened to me – the TFS Job Agent might not report the state and it may goes on for hours, even if it has released all the resource locks.

You can safely stop the job by invoking the Web Service on the TFS Application Tier – you’ll need to set the SetAnalysisJobEnabledState to FullyDisabled first and then to Enabled in order to restart with the next scheduled job.

And remember – do NOT process the TFS_Analysis OLAP cube with SSMS, as it is not supported by the Microsoft CSS.

How did I learn to get on well with Git

Wed, 13 Aug 2014 20:56:00 +0000

Who knows me certainly know I am not the biggest…err…fan of Git

Thanks to Gian Maria and its continuous support on it I managed to understand how Git works and why it is so powerful. I am not saying it is “better than” something else – it is different and it has some pros and some cons.

So, it’s distributed. Distributed does not mean anarchist – it means distributed. If you want to have some sort of centralisation, go for a Remote. You can use it as a shared repository to be used like a central depot without losing any advantage of the DVCS concept.

When you commit something is different than when you push something. A commit is local, a push is toward a Remote.

A Git Fetch gets all the objects from the Remote which are not in your local repository. A Git Pull does more: it merges those files on your local repository, like a Get Latest Version.

Eventually – install SourceTree. It’s an amazing GUI tool with a fantastic branch visualisation tool.

Can’t refresh the TfsOlapReport connection? Have a look at the Trusted Data Providers…

Mon, 04 Aug 2014 09:19:00 +0000

You open the SharePoint Dashboard and you suddenly see this error:

An error occurred during an attempt to establish a connection to the external data source. The following connections failed to refresh. TfsOlapReport

Fair enough, something happened to the Excel Services. Does it? Actually not – and if you try opening that specific report you will see your local Excel refreshing the data and working as usual.

What happened?

That specific error is a generic refresh error in our case. I tried back and forth on all the usual suspects – SSAS permissions, SSS token in the file, SharePoint settings, even firewall ports – but nothing changed.

Suddenly I noticed some reports were working (the Burndown one for example) while this (Active Bugs by Priority) didn’t. So what?

Looking at the Connection String I saw the Burndown report had MSOLAP.3 as a provider, while the broken report was using MSOLAP.5…

A quick double check on the SharePoint server (Manage Excel Services Application –> Trusted Data Providers) brought to the solution: MSOLAP.5 was not listed as a Trusted Data Provider.

Once I added MSOLAP.5 to the list everything worked as expected again and the reports were correctly showing.

Demystifying the Scrum of Scrums

Tue, 15 Jul 2014 20:47:00 +0000

The Scrum of Scrums is often saw as something ‘which grew out of control’, ‘just for Scrum Masters’ or something suited just to very large organizations.

It isn’t, actually…and it’s not rocket science, either.

A Scrum of Scrums is the best possible way of clearing doubts and questions raised among teams. It must not be merged or confused with a bigger standup meeting (as I’ve heard it…) because it is something brought on by the teams’ representatives – the Scrum Masters.

Its scope is to get a clear understanding of the problem’s domain and provide a solution – as the Scrum Master is there to remove impediments.

And yes: a Scrum of Scrums can have its own backlog, Jeff Sutherland defines the Scrum of Scrums as “…an operational delivery mechanism”, so having a backlog is perfectly reasonable.

Why is the new VSO Stakeholder Plan a game changer?

Thu, 10 Jul 2014 08:49:00 +0000

Yesterday Brian Harry announced the new Visual Studio Online Stakeholder Plan – basically, full access to Work Items only in Visual Studio Online (and on-premise Team Foundation Server) for everybody, free of charge.

I believe this is a true game changer: it’s at least four years that we talk about ‘involving stakeholders in the process’, ‘synergy among the parts in the organization’, Product Owners, etc. We could do that, for a fee (the Visual Studio Online plan or the on-premise TFS CAL) but it was perceived as a bit unfair against who could use that CAL/plan at full power (a developer would use all the features provided by the platform, a stakeholder certainly wouldn’t, 99% of the time).

Right now there are no excuses anymore as you can involve as many stakeholders as you wish without paying a penny.

As there are evidences of how involving stakeholders in the development process is a staggering improvement compared to other methodologies, it is a great opportunity to push hard on the quality pedal and starting to achieve great results!

Test Suite and Test Plan customizations in TFS 2013 Update 3 – synergic work between development and testing

Tue, 08 Jul 2014 10:17:00 +0000

IMHO the most exciting feature of Team Foundation Server 2013 Update 3, among all its goodness, is the migration of Test Suites and Test Plans to plain Work Item Types – and the reason is pretty simple.

Despite all the effort spent, developers and testers still had a tiny line which kept splitting them and their worlds:

Which eventually led to limited shared information (pinned items on the Web Access) between them. Which was a cause of pain and frustration, especially among the testers. Using Tags was a way of sorting it, but to be fair not properly the best…

But right now all the testing artefacts are Work Item Types – Test Plans, Suites and Cases – so you can query them and, mostly important, you can easily add custom fields, rules and workflows like with the existing WITs.

For example, I might have Test Suites with a specific Feature Area (potentially reused across other Work Item Types) as well as a Planned Release field. I can easily add them to the Test Suite Work Item Type:

The cool stuff is that all of these are now queryable!

…and obviously, pinnable to the team’s home page:

That’s why it is way easier for testers now to access and share relevant information.

TFS Audits – how to create reports on your TFS usage in five minutes or so…

Mon, 07 Jul 2014 15:12:00 +0000

Some months ago I wrote about the TFS Audit Log, because a big part of my daily job is about governance, regulation and access management.

This log is very, very, very verbose as it is a flat list of every single user and group into the Team Foundation Server’s ACLs. How to get some more meaningful information from it?

The basic Sort functions, together with the Text to Columns of Excel are a must in order to format it in the best possible way. You can then create a PivotTable and mix/match your data and the criteria you want to show:

This fairly basic PivotTable is going to give you this result:

It is basic, but it is something you can do in zero time. Add a chart to the mix and you have a nice (reusable, as you just need to replace the datasource, which is the whole original Audit Log. So in case you need to do it monthly you just need to replace the appropriate sheet and you’re done) report for understanding the ratio between users and group, without the need of complex SSRS reports or even PowerPivot.

Then for instance…if I want to get a text document with all the users contained in each TFS group, the only command I need to launch is tfssecurity /imx. As I have hundreds of groups it is quite…long for a manual interaction. So, I’d create a text file with all the groups - copy, paste from the original audit log, one for each line – and then launch the following command from the Visual Studio Command Prompt:

for /f "tokens=* delims=," %l in (<path to groups.txt>) do tfssecurity /imx "%l" /server:http://<tfs>:8080 >> <path to mygroupaudit.txt>

this simple command is going to execute tfssecurity /imx for each group and, thanks to the >> sign it is going to append the tfssecurity’s output to the mygroupaudit.txt file. I usually launch it on an unattended machine and keep it running on the background until it finishes.

Then in order to get a basic but polished report, open the resulting file in Word, and change the font setting to Bold for these four lines, except for the very first on top which are IMHO useful for a nice presentation:

Done.
Microsoft (R) TFSSecurity - Team Foundation Server Security Tool
Copyright (c) Microsoft Corporation. All rights reserved.
The target Team Foundation Server is http://<tfs>:8080/.

Word has a very useful feature for this needs: select text with similar formatting. Do that and wipe those lines away! You’ll get something neat and polished – change fonts, and add whatever else you need and you’ll get an Audit Report in five minutes :)

Of course it’s possible to use that file in a better way, but these basic tips will give you something in a near-to-none time!

Going slightly deeper in the reporting technologies – PowerPivot is perfect for that. You just need to load the .csv file and you have a dynamic model perfect for drill-down queries. With this:

you’re going to get this chart:

which is pretty basic. But what if you want to know how many users with Full Access (which require a CAL as we know) accessed the server on a specific date…well, you can create a chart having Last Accessed UTC on the Axis as well as on a Slicer, so you can filter your timeframe – and Sum of Full on the Values:

But as it is PowerPivot, you can drill down as you wish…so if from my dates selection I select just today at 13:09 (where this is the only access for today on this test instance, by me) and I drill down by Display Name what I get is …

…a big pie with just me as a value:

These are just easy samples, but as soon as you get that this csv data is a data source…the whole reporting world will welcome you!

Visual Studio Online and Service Hooks!

Tue, 01 Jul 2014 11:01:00 +0000

Despite Visual Studio Online is a Cloud Service – so something you do not have on-premise and where you have limited room for customization – it has been recently updated with a critical feature: Service Hooks.

A Service Hook is, like the name describes, a way to integrate 3rd party services with Visual Studio Online. They are based on the REST APIs provided by VSO.

Let’s say we want to leverage on customers’ feedback like Microsoft does, using UserVoice. It is a great way of interacting with our users – so why not? We are using Visual Studio Online as our ALM platform: how can we accomplish this mission?

It is easy actually, but you’d be stopped up front by Visual Studio Online when you try to create a new Service Hook to UserVoice:

“The Next button is blocked? Why? I thought it was easy!”

Again: it is! But if you read, it says “Subscriptions for this service must be created and managed at uservoice.com.” which means “Service Hooks can be bidirectional, and this service isn’t.” No big deal anyway, because once we logon to UserVoice we are going to find this under Settings –> Integrations…

Easy peasy. Just link your Visual Studio Online account…

Once you are authenticated you can define which Work Item Types are going to be mapped to UserVoice ideas, and in which Team Project of course:

…and that’s all!

Refreshing the Visual Studio Online Project Administration page will show the new subscription – it is managed on UserVoice so VSO is just a client, but of course you can check it from VSO as well!

It just means that in case you’d try to edit the Subscription, you’re going to get this error:

because you need to manage it from UserVoice. Nothing serious though.

As soon as we start receiving feedbacks, we can promote them to Work Items:

And eventually we are going to get them in our selected Team Project. I can open it straight from UserVoice as well!

And keep in mind – you can extend it even more as Visual Studio Online is already set for Web Hooks, which means your own service.

Review – Professional Team Foundation Server 2013

Mon, 30 Jun 2014 21:00:00 +0000

It is The Book. It’s the book you should have on your desk, library, shelve, whatever if you are working with Team Foundation Server.
I can describe it as a the most comprehensive book on the matter, the go-to reference when you need to plan/understand/troubleshoot something on TFS.
The 2013 edition is even better than the last year’s one, covering Git and the Distributed Version Control System, Visual Studio Release Management and all the new stuff of the latest version – Visual Studio Online included.
Everything is very smooth and in deep as you’d expect – you won’t find generic stuff or something about Visual Studio or MTM. If you are searching for them, you should see other books. It is not a pure beginners’ book: the planning section for example is very specific.
But even if you are a regular user, you are going to get a lot of value from the book. I strongly suggest it to everybody, from who uses TFS every day who wants to understand what goes on behind the scenes to the hard-core Team Foundation Server Administrator.

How to use PowerShell DSC with Visual Studio Release Management

Wed, 18 Jun 2014 10:46:00 +0000

After the brief introduction earlier this month it is now time to push forward – let’s see how the Update 3 CTP of Visual Studio Release Management enables you to push your DSC scripts to the target machines.

Firstly, the script. To keep things simple, I decided to deploy my script in an independent build and then leverage on VSRM for the deployment – no build template integration.


[sourcecode language='powershell' ]
Configuration DemoAppConfig
{
    param($servers="localhost",
    [String]$SourcePath = '\\dtfsat\Build',
    [String]$AppPath = 'C:\AppPath'
    )
    Node $servers
    {
        File CopyApp
        {
        Ensure = 'Present'
        Type = "Directory"
        Recurse = $true
        SourcePath = $SourcePath
        DestinationPath = $AppPath
        }
    }
}

DemoAppConfig

[/sourcecode]

Then we can create a new Standard Environment:

which is going to contain our agentless target server. To configure a target server, you’d need to run Enable-PSRemoting –force and winrm qc –transport:HTTP from PowerShell.

This server must be added using the FQDN and the listener port – the 5985 is the default port used by the HTTP listener.

This server is always going to be in a Ready status as long as there are the required permissions in place.

The only missing bits are the Component and the Release Template. As mentioned, the Component is going to be picked from an external network share (the build drop location) and used as-is. This is just for this sample anyway, the standard Build Definition used by VSRM would work as usual.

The big difference stands in the Deployment Tool used for the component – it is going to be Run PowerShell on Standard Environment, which provides all the facilities for running the DSC script:

This is going to be our single entrypoint for running DSC script. Moreover – if you look at the Release Template toolbox it is quite…empty:

But it would work like a charm :) The Deployment Sequence is going to be pretty lean as well: invoking the Component’s deployment for the target server – and that’s all:

This is what you are going to need to create a basic DSC-based deployment using Visual Studio Release Management. No rocket science required!

A quick look at the Team Foundation Server’s permissions inheritance

Wed, 04 Jun 2014 14:21:00 +0000

Straight with the sample – why does it happen…

…even if my user is a Project Administrator?

Because the single user’s permission are less important than the Team’s one – and as in this team there is a explicit deny on that permission (Edit project-level information) even if he is an Administrator he is going to get a deny.

Indeed…

That’s because you can be the CEO, but you won’t be allowed to change the delete the Team Project on your own if you’d be fired, for example :)

PowerShell DSC – extreme automation in a DevOps world

Sun, 01 Jun 2014 06:32:00 +0000

Release Management Update 3 CTP1 introduces support to PowerShell Desired State Configuration to deploy applications in your environments – this is utterly cool, but…why?

Before looking at VSRM itself, I think a bit of introduction to DSC is needed.

PowerShell Desired State Configuration is a new management platform built-in in Windows and based on, guess what, PowerShell. It can do a bunch of useful tasks, which I leave to the documentation because I just want to dig into the core concepts.

As it is built-in in Windows, it is agentless. Well actually the agent is inside PowerShell and Windows Management Framework, but for our purpose (deployments) we can consider whatever system running PowerShell 4.0+ (so Windows Server 2008 R2 and above, just by installing PS 4.0 and WMF 4.0) a DSC-capable system.

All of that goodness relies on a keyword – Configuration. If you set a Configuration block at the beginning of the script, you are invoking DSC.

DSC uses a .mof file which is created by the script itself, so after creating and running the script you just need to call Start-DscConfiguration with the appropriate parameters.

Let’s see a code snippet, it is very easy to use

Configuration InstallFX35_45
{
    param($servers="localhost")
    Node $servers
    {
        WindowsFeature Net-Framework-Core
        {
            Ensure = "Present"
            Name = "Net-Framework-Core"
        }

        WindowsFeature Net-Framework-45-Core
        {
            Ensure = "Present"
            Name = "Net-Framework-45-Core"
        }
    }
}

Here it is. The Configuration block is called InstallFX35_45 – it will check for the .NET Frameworks 3.5 and 4.5 on the target servers (or on just localhost if not specified) and, if any of them are not present at runtime, it would automatically trigger the installation of what’s missing via Install-WindowsFeature.

We just have to launch it, to get the .mof file, and invoking Start-DscConfiguration:

InstallFX35_45 -servers "PTFSDT", "PTFSAT"
Start-DscConfiguration -Wait -Verbose -Path .\InstallFX35_45

Everything is handled by the OS – so what we should care about is the whole configuration, nothing else. This specific solution addresses almost all the needs we might face in a DevOps environment – and in a very robust way!

DSC scripts are idempotent – so you can reapply a change and get to your desired state (hence the name…) regardless of the current status. No complex logic for catching exceptions or incremental changes – all is handled by the underlying infrastructure.

You can use DSC for installing roles, services, interacting with IIS, copying files…all from PowerShell, and in a completely reproducible environment.

The PowerShell team released a very handy Resource Kit, to get started with DSC and, eventually, DevOps – you can download it here.

Shared Parameters in Web Test Case Management

Fri, 23 May 2014 14:00:00 +0000

With the latest Team Foundation Server update (2013.2) we get a very useful feature in Web Test Case Management – Shared Parameters.

We had it in MTM, but not in the web. Right now instead I can write a generic Test Case and populate its values from the Web Access as well:

At execution time I am going to face multiple iteration of test cases, one for each line of parameters:

WTCM becomes cooler and cooler at each release!

The TFS’ Excel Reports won’t load after a SharePoint change – why?

Wed, 21 May 2014 15:52:00 +0000

I experienced a situation where the SharePoint instance used by a Team Foundation Server suddenly started raising errors while loading the Excel Reports inside a page.

The error was “An error occurred during an attempt to estabilish a connection to the external data source. The following connections failed to refresh: TfsOlapReport”

But – if I tried to open them they were fine, after a refresh. What the heck?

The answer seems easy for a SharePoint expert but not for someone who tries to steer clear from it…:) basically the Secure Store Service is used to authenticate the requests TFS does using the SharePoint’s services.

Here is the issue – do not ask me why, but after a change on the SharePoint side (possibly due to a reconfiguration), the Authentication Setting for my report’s connection changed. In order to work, the report must use the “TFS” SSS token – and not the user itself.

After resetting this, and double checking the SharePoint settings together with a specialist, everything worked as expected.

Why bringing evidences to the Sprint Retrospective meeting?

Sun, 18 May 2014 15:35:00 +0000

The most common question in all the situations of an average software development project is not “How?” but instead “Why?” – and in particular:

“Why did we do/act/decide that way?”

With the wealth of technologies available today it is not a matter of how anymore, because a new framework, a new tool comes up every week so we do not face the same technology challenges as twenty years ago – today is all about the why, because we can tackle the same problem in many different ways but each solution is going to have something special.

This is why I bringing evidences – when needed and possible, of course – to a Sprint Retrospective meeting becomes real value for the team.

“During this sprint we did this because we found out that: …”

Making this an habit improves the quality on the long term: if you enter this information throughout the development, ideally at each Sprint Retrospective, into a wiki it creates an informal and backed knowledge base which will surely be reusable in the future.

There is a high value behind this task: you are tracking all the decisions made during the project. It is also a basic form of Evidence-based Management if you wish, with all its pros.

Troubleshooting users’ issues with the Team Foundation Server Operational Intelligence

Tue, 06 May 2014 14:15:00 +0000

I tried to do something on the TFS but I got this error … Why?

Fairly common situation for every TFS Admin on this planet and beyond. How to quickly get grip with the problem?

As usual in this cases, the answer is one: with the TFS Operational Intelligence.

It is enough to go in the Activity Log page (http://mytfs:8080/_oi/_diagnostics/activityLog), selecting the Project Collection (or the server itself if needed, but this would be useful just in case of errors not related to the Project Collection itself) and filtering by user account.

From the results, whatever line has a status of –1 is the one which failed:

For instance, for my obscured user (you can see the PRO as part of the domain name, I had to remove it :) ) it is an error coming from the Team Foundation Build – he fails to list the builds.

If you open the Details for the error itself, you can get all the details about the issue:

His PowerShell script is failing because it is probably trying to get a Build Template which doesn’t exist. A couple of questions (and ten minutes later) he was up and running again.

Review – Professional Application Lifecycle Management with Visual Studio 2013

Mon, 05 May 2014 21:34:00 +0000

After Professional Visual Studio 2013 it is now time to go a little deeper on Visual Studio ALM – Professional Application Lifecycle Management with Visual Studio 2013 is out!

The book itself confirms its aim – being the one stop guide to the Visual Studio ALM platform.

It has been fully updated, including Git, Visual Studio Release Management and Visual Studio Online. All the previous’ version chapters have been reviewed and revamped with the latest bits and everything is new.

Personally, I really liked the Chapter 4 – a quick introduction on Git, to let Visual Studio users being updated with the latest tool around. It is not easy, I am still digging into that as well, but Ch4 serves its role in a perfect way.

So, it is time to update the libraries folks!

Can Scrum and CMMI live together?

Tue, 29 Apr 2014 21:39:00 +0000

TL;DR version – yes.

Many think that Scrum (and Agile in general) and CMMI cannot live together. After some years researching about that, my opinion is that this assumption is false.

Let’s keep things simple – CMMI is based on a binary process: planning plus execution. We have a (sometimes very) high level planning, each hierarchy level with its requirements and so on.

Can the execution phase keep on with that? It can – breaking down large features into smaller PBIs and then tasks is not something exclusive to Scrum but it can be applied to CMMI as well, with great results.

The Definition of Done as well can be integrated as a part of the CMMI Requirements and criteria, this is another simple yet effective example.

The CMMI Institute has a very interesting article digest on the topic – I really like this quote from the above:

As an Agile method, Scrum promotes frequent inspection and adaptation, teamwork, self-organization, and accountability. CMMI focuses on improving processes to improve performance.

And what about TFS? Well…all the tools are standard regardless of the Process Template, so the answer is obvious again.

How did I manage to get on well with Git

Sat, 26 Apr 2014 12:57:00 +0000

Having to deal with Git when you come from years of another Version Control System can be hard – I was very comfortable with the Team Foundation Version Control and in the rare cases I needed a distributed VCS my choice went to Mercurial.

I was very biased against Git, for several reasons. But then, after using it and dealing with it at work, I managed to find a position for it in my toolbox. Let’s see the reasons which made me accepting Git

Git is different

Yes, indeed. It was born with a specific purpose (VCS for the Linux kernel) and with a specific target in mind – kernel developers. Git is sometimes counterintuitive and not consistent, you have to learn it from the ground up without comparing it with other VCSs.
Despite it is a VCS, you can change the history of your source tree for example. You just have to understand that it is different, that’s all.

It is a great tool to be used with Team Foundation Server

Team Foundation Server is maybe one of the most interoperable product at Microsoft, and including Git inside it has been a marvellous choice.
You can have heterogeneous projects thanks to it, and even use it together with the TFVC if you want – with git-tf. And do not forget the migration capability – there are countless tools for migrating from other VCSs to Git.

It is lightweight and fast

Despite its steep learning curve, once you are familiar with the basic commands Git is blazingly fast and lightweight – thanks to its distributed nature.

These are the main reasons which led me to live with Git without fighting with it. I am still a learner on the subject though, maybe in the future there might be a revised version of the list. Let’s see

How to check for Team Foundation Server’s job running time

Tue, 15 Apr 2014 11:26:00 +0000

This is very quick but helpful IMHO.

Scenario: you are an external consultant and you need to run a job from the Team Foundation Server web services (ProcessWarehouse, just to mention one of them), but you cannot access the server itself because of some security policy.

You ask someone in the IT department to run it on behalf of you, but of course you want to check how long does it take. How?

By using the TFS Operational Intelligence. If you check the Job Queue list, you will get all the running and scheduled jobs for the server.

If a job is running you will get the actual running time, otherwise the last execution’s time.

Review – Professional Visual Studio 2013

Sun, 06 Apr 2014 20:30:00 +0000

Another year, a new IDE, a new book about it.

Do you want to compare it to the last year’s one? Fair enough – it is an updated overview of the Microsoft development stack. This is enough to justify it in full.

Bruce Johnson (Visual C# MVP) refreshed the 2012 one, covering a huge (1050 pages) amount of topics. Of course it is not a deep dive style book, it is not its target, but it gives the right amount of information on everything surrounds the core topic – Visual Studio itself.

To summarize in one idea: if you see something in the IDE, it is covered here.

Again at the end, Visual Studio Ultimate and Team Foundation Server are separately reviewed in order to avoid polluting the core stuff. A great choice I fully back, by the way.

It is a book every developer should have on the shelf, because sometimes picking up a specific chapter is better than just searching on the MSDN or a search engine.

IISReset and TFSServiceControl quiesce

Sat, 22 Mar 2014 13:11:00 +0000

“Isn’t it the same if I just run IISReset /stop to take the Team Foundation Server down?”

No, it isn’t.

If you just run IISReset /stop, you are just locking the IIS access – but the Team Foundation Server is still up and running, it is just not reachable.

This is why TFSServiceControl quiesce is needed: by running it, you are effectively taking down the server, stopping the Application Pools, all the jobs and the agents running on it. Moreover, MSDN states “You cannot manually perform all of the tasks carried out by the TFSServiceControl command.”, so little choice here

Other than being sure of the TFS’ status and consistency, by running it together with IISReset you are ensuring that the IIS won’t be overstressed and it won’t forward any query to the TFS itself.

Basically, you are locking the safe (TFS) and the room’s door (IIS).

Suggestions for preparing a TFS deployment with SQL AlwaysOn

Tue, 11 Mar 2014 10:27:00 +0000

SQL Server AlwaysOn is a utterly cool technology, but it is not a technology itself which solves all the problems you may have.

In particular, it is not just about tweaking a couple of settings and adding servers as needed. A careful planning and thorough tests are mandatory in order to succeed without affecting the existing service or going overtime. So I wanted to sum up some tips I found during a project I am following with a huge deployment of Team Foundation Server 2013 which uses SQL Server AlwaysOn as an underlying High Availability solution.

Size your storage
I am dealing with TBs of data, so I am experiencing that TBs of storage flies away in a snap. Do not underestimate your storage size and do not rely just on SANs. Importing your data takes time and space, especially if you restore your databases to the secondary replica using the Full mechanism of backup-and-restore provided by SQL Server AlwaysOn.
You can’t mix and match all the HA technologies
Not all the SQL HA technologies are supported by TFS in the first place. MSDN is pretty clear on this, no replication and no log shipping. Log shipping could technically work, but you won’t be supported by the Microsoft CSS, so it is a no no. You can mix a clustered SQL Server with another one in another location within the same AlwaysOn Availability Group though, and it is pretty robust. Keep in mind anyway that TFS is pretty agnostic about the underlying SQL deployment though, in fact the only feature which requires a specific configuration is AlwaysOn Availability Groups.
The MultiSubnetFailover setting
When configuring Team Foundation Server for using AlwaysOn Availability Groups, remember to tick the specific checkbox about this setting. Beware of the setting: if you are not directly using an AG but you select it at TFS configuration time, you are going to be in trouble. If you are restoring it to a new server, launch TFSConfig RegisterDB to enable it:

TFSConfig RegisterDB /SQLInstance:MyDB\namedinstanceifneeded /databaseName:Tfs_Configuration /usesqlalwayson
All the Team Foundation Server databases must be in the AlwaysOn Availability Group
No exceptions to this – if you use it, all the DBs must be contained in the AG.

How to perform a TFS Security Audit

Sun, 02 Mar 2014 14:46:00 +0000

It is common to be asked for performing a security audit on Team Foundation Server, and it is not a nightmare as it would seem…

The easiest way is to download the Audit Log. You can find it in the Access Levels administration page:

What you are going to get is a .csv file, containing all the groups and accounts allowed into Team Foundation Server, each with its unique internal URI (vstfs://…), the last access date and its access level.

But this is just the beginning – you get a list of flat users and groups, without their relationships. In order to get these, you can use the TFSSecurity command with the /i, /im and /imx switches.

These will give you all the informations about each user/group and its relationships and privileges, so wrapping their outputs and creating a very simple report is just a matter of time

Why shall I use Application Insights?

Tue, 18 Feb 2014 19:54:00 +0000

There has been a lot of noise around the latest kid – Application Insights on Visual Studio Online.

It is a fantastic solution, but I did not clearly stated anywhere is:

Why shall I use it?

I think the answer is pretty easy – everybody needs diagnostics and logging while in production. It can be expensive to setup a custom solution, which spreads among different devices, different infrastructures (cloud anyone?), different networks.

Application Insights is a great solution for that, as it provides a broad range of features aimed at addressing almost every scenario in that field.

For example, the possibility of downloading an IntelliTrace file from an exception which has been logged on a specific error is just invaluable, providing all the information I might need for fixing that specific issue.

Or talking about usage – how handy can it be a service which collects and aggregates all the information related to my usage data from my real users.

I mean, from the page pattern they follow to the device they use, it is a range of data who can be used in many ways, from diagnostics to marketing. Why losing it?

As we know, integrating it is a matter of adding some JavaScript lines, a couple of files or a bunch of lines of code depending on the platform we are targeting – this is why it is really worth integrating it in our projects: with a minimal effort we can get a giant stream of information to use as a source for a broad range of tasks, not just developer-focused ones.

Application Insights Visual Studio Add-in preview – what is that?

Sun, 16 Feb 2014 09:09:00 +0000

Brian Harry recently blogged about that, this is an add-in for adding Application Insights’ telemetry straight from Visual Studio itself.

It is helpful, because once you install it you can add AI to all your new projects OOB:

It is already tied to your Visual Studio Online account (after a login, of course). Then it is going to automatically detect what project type you created and it is going to set it up for AI in a snap.

SQL Server AlwaysOn with Team Foundation Server – a great team!

Tue, 04 Feb 2014 16:43:00 +0000

High Availability and Disaster Recovery are the first two items on the list for a TFS Administrator, as Team Foundation Server hosts a critical service for almost every company with a linked development team.

Frankly in the past delegating the HA story to someone else in the organization was a very common practice, as it is not something related to TFS – which is pretty agonostic about the SQL Server deployment topology or about the number of Application Tiers.

If you want to use SQL Server AlwaysOn in your deployment – apart from all the other technologies which can be involved (Windows Failover Clustering, SQL Server Clustering, VMs redundancy, etc.) – the only configuration needed is to create a SQL Server AlwaysOn Availability Group. You are going to get a replication between up to four different SQL Server instances so you can failover at anytime.

Given a Windows Failover Cluster and two different SQL Server instances, one on each node, you just need to do as it follows:

You launch the wizard, and you specify a name and, for now, no databases are going to be contained inside the Availability Group.

Then you can select the replica mode (synchronous or asynchronous) and you must specify a Listener, which is going to become the instance name you are going to use to configure Team Foundation Server.

Then – while configuring Team Foundation Server using the Advanced mode - you are going to need to specify the Listener and tick the box saying that it is a SQL AlwaysOn Availability Group. TFS will then configure some specific settings for it in the process.

It is extremely important to add all the databases, and each database must be backed up, otherwise you won’t be able to add them to the AG.

Eventually, do not forget it is not the only HA solution, and a good HA solution is composed by several technologies working together on a minded plan :)

Here you can find the MSDN page for the topic.

New sprint, new release for Visual Studio Online

Thu, 23 Jan 2014 13:37:00 +0000

Microsoft just released a new sprint of Visual Studio Online, the first one of the new year.

Three small but valuable items contained inside: Tags Querying, the possibility of removing weekends from the Burndown Chart and finally, Configurable CFD Dates!

I wanted to highlight the first one: it makes the usage of Work Item Tags extremely powerful now - adding this feature means we can now have another level of sorting, completely independent from the hierarchy.

One example? You can have a quantitative analysis of your Work Items, grouping them by a specific tag. Or, if you use a single Team Project approach in a consultancy scenario, using tags to create an independent sorting label for customers.

The latter two instead are very helpful for reporting purposes – removing weekends is essential to have a clear view of your sprint, instead of applying some kind of correction because you have weekends in the middle, and the Configurable CFD Date makes possible to drill down on your CFD in a snap.

Groups Synchronization in Visual Studio Release Management

Wed, 22 Jan 2014 15:47:00 +0000

Why can’t I see my updated Active Directory groups in Visual Studio Release Management?

It is a fairly common question. And the answer is pretty easy: by default, there is no automated synchronization.

In order to manually sync them up, you should press the Refresh button in the Manage Groups section of the VSRM client.

But what if I want to have an automated synchronization?

The setting to change is the AD/TFS-Based Group Refresh Interval.

Set it to something different than 0 (minutes), and VSRM will start synchronizing your accounts every interval you defined.

Easy peasy

Find hidden information in the Visual Studio Online Application Insights portal

Wed, 15 Jan 2014 10:37:00 +0000

No, I am not talking about something secret or left around. I am talking about when you skip the adventure to, for instance, set up Usage Monitoring of an application and you cannot find the code snippet anymore. Or the Instrumentation Keys. Or…:) You may struggle to find them, and do not use the same snippet of another application – you will monitor the right one in the wrong place. So, here they are:

Just by clicking the Control Panel button:

You will find all you need for each application you want to instrument:

In the Keys and Downloads tab you will be able to regenerate each key as well, in case you might need it.

Custom Synthetic Monitors in Application Insights

Tue, 07 Jan 2014 16:46:00 +0000

We know it is extremely cool being able to monitor a website’s availability using the Windows Azure data centres all around the world,

but what if I would want to monitor a specific usage pattern? It is extremely easy – I would create a multistep web test.

Just create a new Web Performance Test:

Once I am ready, I can start recording my usage pattern:

That’s all! Once saved, from the Application Insight Availability Hub I can then add it, as a Multistep Web Test:

Now I have to upload it, and the only missing step would be selecting the required locations I want to use as a test site, the test frequency and an alert email if needed.

Visual Studio ALM MVP, again

Thu, 02 Jan 2014 16:12:00 +0000

Every year since 2010, the first day of the year is marked by the email from the MVP Award, and this year is no exception: I have been reawarded this year as well, for the 5th year in a row on Visual Studio ALM again :)

It is a huge pleasure and I am really honoured by this, and moreover this year with the relocation and all the other changes it has been harder.

I definitely need to thank Claire, my CPM, and the whole Visual Studio ALM team for this.

I will always do my best for the technical community all around the world, as it is something I really enjoy doing, so let’s see what happens during this 2014!

Keys for a painless TFS upgrade experience

Sun, 15 Dec 2013 21:00:00 +0000

This weekend I had to work on the upgrade of the main Team Foundation Server we have in production. Everything went fine – despite not everything according to the planned slick idea we had. The whole thing has been longer than just yesterday, though, and it comes with several takeaways.

Here’s what, of course involving our shiny Team Foundation Server 2013. Keep in mind the scenario: thousand of users all around the world, terabytes of databases. Here we go:

Plan, but do not overplan.
We had a plan but you cannot cover anything. You cannot plan every single step and do not have a B, C, D plan. I am not talking about not having a plan, but I suggest of being confident and flexible.
Start planning with enough time, so the right guys are involved, and keep in mind the basics of TFS and its known issues, the history of the server (in our case it was essential) and use the TFS Upgrade Guide to have a guideline to follow.
Test the core, test the basic.
This TFS survived through upgrades from 2005 on, we discovered what we thought impossible. Your team’s skills will let you fix the problems you might find.
So test the core, verifying that all the essential pillars are working. If you find out issues, try to fix them or plan a deferral (maybe with the CSS?) if they are not critical.
Do not start trying the latest, better tech combo. As a sample, do not start upgrading the test server to 2013 and upgrade the build servers as well. Test the existing servers (or clones of them) against the 2013 server, and only when you are sure of the result test the upgrade of them.
File as much documentation as you can but – again – you cannot cover the 100% of cases.
Problems are problems if they come out just in production. Otherwise they are issues to fix.
You might find something to fix at a later time, which does not impact all the users but maybe a small percentage. You can work it out later.
Instead, for instance, we hit a very nasty problem during our live production update. We had no plan for it, as it did not happen in the test. What did we do? We tried several solution (one worked, luckily ) while someone else worked on a mitigation plan to use in case no solution was fine.
We did not have to use it, but if you are running a service, you have to make tradeoffs and stop the whole service for just a part of it is unacceptable.

Remember that Team Foundation Server is modular, so you can exclude a part of it in case of problems, and that usually the upgrade compatibility for who comes from the last version (2012 in our case) is almost effortless.

A pragmatic approach to a better manual testing

Tue, 10 Dec 2013 15:05:00 +0000

I recently had to deal with a small Functional Testing Team (two people in total) which was used to have a non-structured approach to manual testing, with several Word and Excel files used to track down the required information, absolutely no automation in place and a very personal way of dealing with issues reproduction and environments.

I thought that giving them all the Visual Studio ALM features was surely going to be overkill. Quite a greenfield situation, but combined with the requirement of retaining their habits and their knowhow as much as possible.

The first step is converting the sparse information they have as test cases into Test Cases in Team Foundation Server. It seems obvious, but it is not. You have to set up a descriptive standard, detailing steps and expected results, so that everything is coherent with the actual target but they feel comfortable with the new tool (MTM) and process.

It is also extremely important to standardize a bit the environments they work with. If they use their own local machines, set up a standard about not just toolings, but even how to reach them. If you do this, a newbie tester can be thrown in the mix and be able to start working in a near-zero time. Once they are aware that they can replicate their recordings and they can get even the videos, they will go nuts. But it is not enough…

The next logical step is either converting their action recordings into Coded UI tests or using Lab Management. There are valid reasons behind both:

Coded UI Tests	Lab Management
Validation	Standardized environments
Extended behaviours	Complex configurations
Integration with Visual Studio	Commodity for the members

You could take both of course, but it depends on the resources you have. I went for the Lab Management route – as they are pure functional testers, so with very little code confidence - and they are happier and more productive than ever.

New TFS Upgrade Guide out!

Wed, 04 Dec 2013 11:20:00 +0000

The ALM Rangers just released the v3 of the TFS Upgrade Guide. Apart from the official announcement, etc., I wanted to give you a valid reason to download and use it if you are still sceptic.

Scenarios. This guide covers a handful lot of real world scenarios, like the upgrade from 2008 or different configurations. So it is not just a basic walkthrough, but it provides you a robust sample from people who already experienced the aforementioned scenarios.

Give it a try, you won’t regret it ;)

Recap of the Visual Studio launch!

Wed, 13 Nov 2013 20:00:00 +0000

So, very packed day!

Visual Studio Online is among us. Nothing more than Team Foundation Service up to yesterday, but now with a lot more.

First of all: the plans. We now have three plans, Basic, Professional and Advanced. The Basic and the Professional one expose the same set of features, apart from the fact that the Professional one includes a monthly subscription for Visual Studio Professional. Yes, the IDE! And of course you get five users for free with the Visual Studio Online Basic plan, as of today.
The Advanced one is another story – it is the biggest one, but without the IDE subscription.

Codename Monaco is something incredible - finally they managed to deliver Visual Studio (well, part of it I would say) through the browser. Yes. Visual Studio in the browser. Just for Azure Web Sites at the moment, but still awesome!

InRelease changed its name, becoming Release Management for Visual Studio 2013. It’s a very powerful solution for delivering artifacts, as we know, and it is perfectly integrated with Team Foundation Server and the other tools.

Visual Studio 2012 got some love as well - the Update 4 is out!

And eventually, Application Insights is the shiny new feature of Visual Studio Online – it fills the gap for a monitoring solution which is not SCOM. But keep in mind – you can use both! Here is my introductive post about that.

Application Insights in Visual Studio Online

Wed, 13 Nov 2013 16:14:00 +0000

One of the coolest things about Visual Studio ALM is that it is a continuously evolving platform. Application Insights is the latest addiction to the family, empowering the monitoring story on the Visual Studio Online side.

First of all, you have to download the latest Microsoft Monitoring Agent. This version allows you to configure both the Visual Studio Online Application Insights and the SCOM integration, it is a huge leap on. You can monitor .NET and Java applications, running on-premise or on Windows Azure, and Windows Phone 8 apps.

Then you must enter the Account ID and the Instrumentation Key. Both are unique to the Visual Studio Online account.

It is possible to choose Microsoft Update as a update source. It is the recommended option, and unless you already have another update source (WSUS, SCCM) you don’t have a lot of choice :)

That’s all. After we finish the installation, the configuration command prompt will automatically pop up, scanning your IIS. I am running it on a Microsoft demo VM, so never mind about the TFS applications and the others. The one we care about is the FabrikamFiber.Web.

Now you only need to give the service some minutes of data gathering in order to start composing your data. Meanwhile, one among the big amount of possible choices is to create a summary dashboard – here’s how:

Correct, you only need to set a name and select the Application you want to aggregate data for. It is pretty cool by the way :)

Opportunities are broad – you can monitor the Application or deep dive on a specific performance or reliability value. Keep in mind that it is possible to define a metric in a very quick and easy way, so you can even use your own metrics as a baseline for evaluating the Application’s lifecycle and its values.

Feature Flags, the cornerstone of Continuous Delivery – a jumpstart

Fri, 08 Nov 2013 14:43:00 +0000

I had to talk about that so it is worth to share it there as well!
One of the pillars of Continuous Delivery is the broad usage of Feature Flags in the code.
What’s that? It is a concept introduced by Flickr in their pioneering usage of DevOps and Continuous Delivery, and supported by Martin Fowler as well. To keep it simple, let's make an example: everybody has a control panel at home for electricity. The control panel complexity may vary – it could be simply on-off, or be shaped to split every single room of the house with one switch each. These switches are the Feature Flags.
I guess it is pretty obvious to understand why they should be used. With them, you are improving testability, troubleshooting, and facilitating the incremental shipping.
Of course technology is not everything. You should be backed by a very solid process, otherwise the tentative of being Flickr-like (no branches and just feature toggles) would be a bloodbath..
An easy way of starting could be as it follows:

It is a beginning, we can use Feature Branches to develop features (separation of concerns, modularization design patterns apply here) and merge them to the main development branch. Fairly easy and fairly classic I’d say.
Now let’s go a bit more into the code. As a sample I am using a WinRT App, leveraging on FeatureToggle as a helper. FeatureToggle is a nice OSS library which enables Feature Flags in a very easy way, it was the easiest to set up (NuGet package) and use. And moreover, it works on Windows Desktop, WinRT and Windows Phone. Definitely worth a try IMHO. But keep in mind it is just a sample, with no willing of be production-ready :)
I created two classes with my features inside – I wanted to do the easiest possible example, so don’t mind about the code’s silliness – which implement one of the OOB toggles, simply an Interface.
After this, in the MainPage() I would set (for the example, because in WinRT there are no .config files. In a webapp I would read the web.config file instead) the available features - and of course in the FF.Dev I would get the Yes and No features because of the merge from the feature branches – and then the bounded controls would be instantiated.

If I do not want to enable the Yes feature, I just have to set its configuration value to false, and despite the code is there, it won’t be available to the user. Which is exactly the target of Feature Flags.

Just run the application with the settings you want, and you would get the result. In case of a old-fashioned web application or whatever else, you can rely on XML files (and their transformations, if needed) for configurations.

How to change a TFS GUID and why is it extremely important?

Fri, 01 Nov 2013 16:18:00 +0000

If you are working on a test upgrade of an existing Team Foundation Server by restoring it on another machine, keep in mind it is not enough to discern it from the existing instance.

Yes – you are changing machine names and IPs – but it would be needed to change the GUIDs as well, otherwise the Visual Studio cache is going to go crazy. You have one GUID per Team Project Collection, and they are stored inside the TFS_Configuration database.

You need to quiesce the server first, then use the TFSConfig ChangeServerID tool:

tfsconfig changeserverid /sqlinstance:<your-sql instance> /DatabaseName:Tfs_Configuration /projectcollectionsonly

You can specify if you are running on SQL AlwaysOn as well.

Converting TFS 2008 servers to 2012 and 2013

Mon, 21 Oct 2013 20:29:00 +0000

As you know, Team Foundation Server 2008 had several limitations which prevents a direct migration to 2012 or 2013. It is a legacy release, good at its times but definitely not adequate anymore.
Migrating it through an in-place upgrade to 2010 and then a move to 2012/2013 version (from now on modern) is feasible, but often the server where the legacy version runs is old as well – 32 bit only CPU overall – making the migration path harder because of the move.
There is a very handy tool for dealing with this scenario: TFSConfig Import.
It is meant to convert the legacy server into a new Team Project Collection in the modern instance. It won’t migrate reports or SharePoint, but it is worth using it as it saves a ton of time in the process.
It is needed to move the databases onto the current Team Foundation Server – or upgrade the legacy one to a supported version by the modern release you are using – and then launching the command as an administrator:
TFSConfig Import /SQLInstance:<servername> /CollectionName:<MigratedCollectionName> /confirmed
The /confirmed switch is meant to confirm you have backups of the databases you are converting, as after the process they won’t be compatible with the old TFS.

Visual Studio ALM 2013 is RTM: is it just Visual Studio and TFS?

Thu, 17 Oct 2013 12:33:00 +0000

As we know, Visual Studio ALM 2013 has been RTM’d and released. But is it just a new Visual Studio and a new Team Foundation Server?

Obviously not. Apart from these, we are talking about:

the new Monitoring Agent 2013, which contains a newer and enhanced version of the Standalone IntelliTrace Collector
the new MSSCCI 2013 provider, which enables legacy clients to connect to Team Foundation Server 2013
the latest Team Foundation Server Power Tools 2013
the latest Team Foundation Server Build Extensions

And – as usual - there is more on the Team Foundation Service side every three weeks, with their agile release cadence.

Fix the “Cannot perform 'SetProperty of Text with value “” on the hidden control.” error

Thu, 10 Oct 2013 15:51:00 +0000

If you are trying to use Test Manager to record a manual test with a web application and then play it back, you might find a nasty issue while inputting stuff: the error “Cannot perform 'SetProperty of Text with value "value"' on the hidden control.”.

It is caused by the Microsoft Security Update MS13-069 (KB2870699), which introduces several security fixes as well as this strange behaviour.

To fix it and correctly playback the test, you would need to install the latest Update of Visual Studio 2012 or use Visual Studio 2013 which is not affected.

Microsoft Monitoring Agent 2013 overview

Fri, 04 Oct 2013 13:38:00 +0000

A couple of weeks ago Microsoft released the Microsoft Monitoring Agent 2013, the next generation of the very useful Standalone IntelliTrace Collector.

It is a very interesting tool – as I mentioned at DevReach – because it can be used as a standalone collector or integrated with System Center Operations Manager, being then the foundation of the bridge connecting IT Operations teams and Development teams.

If you want to run it, it is absolutely easy:

What’s next?

A wonderful IntelliTrace file

Review – Professional Scrum with Team Foundation Server 2010

Mon, 23 Sep 2013 08:02:00 +0000

I can already hear the voices…”why are you reviewing a three years old book?” “It is on 2010, it is outdated!” and so on.

Instead – trust me – I would strongly suggest you to buy it, for a simple reason. All the features used and explained in this book are the same or very similar from 2010 on, as we are talking about essential, cornerstone features.
Moreover, the book covers the very needed concepts needed for Scrum, so it is very helpful when you have to introduce a team to it.
The authors (Steve Resnick – Architect at Courion Corporation, Michael de la Maza – Agile Coach and Investor, Aaron Bjork – Senior Program Manager at Microsoft) explain everything with a very good pace and the required level of detail: they go step-by-step in every required part of the Scrum methodology, and at the end you will find a dedicated chapter on Spikes and an appendix dedicated to the Scrum Assessment.
It is very handy to use as a quick reference, just grab the required chapter and you would get your answer.
I am going to use it with a new team to be inducted to Scrum, by keeping it on the table during the daily Scrum and every Meeting. I bet it is going to be helpful

How an automated release looks like – the InRelease side

Tue, 17 Sep 2013 09:00:00 +0000

Once you have an automatic build leveraging InRelease for its automatic deploy, the workflow is pretty easy and straightforward.
Let’s say we make a whatever edit to a file in our project:

We check it in, and we trigger a Continuous Integration build.

Nothing too fancy at the moment. But of course we have to use the InRelease Build Definition Template for using those features, so we are going to see some specific activities in the build log, targeted at this.

The next steps are extremely easy and straightforward: depending on the Release Settings someone designed as Approver should approve the deployment:

Once this person/team accomplished this task, that’s basically all The only missing piece would be approving the Release (again, based on its settings. So it could be avoided, if needed)

A very useful aid is the possibility of scheduling the transition (i.e.: QA to Prod) to a future time, in order to be compliant with whatever company policy you might have.

And this is really all

Work Item Queries Charts

Mon, 09 Sep 2013 18:00:00 +0000

In the latest sprint, Microsoft released a very nice feature for reporting purposes: Charts for Work Item Queries.
It is incredibly easy to use. You do not need anything but Team Foundation Service. You can click on the link while opening a WIQL query:

and creating a new Chart

Finished.

Unfortunately at the moment is just supports flat lists, but in the future it is going to support the two other WIQL resultsets. It is very handy, you can embed it into an email or whatever, and it comes working with no configuration. Well done team!

How an automated release looks like – the Team Foundation Build side

Mon, 09 Sep 2013 12:00:00 +0000

Well, when it comes to the Automated Release our beloved Team Foundation Build has not so much to do…apart from hers usual stuff, with a slightly different Build Process Template.
For enabling an Automated Release, you have to add a custom Template and create a Build Definition using it. You are going to find it into the InRelease installation folder (…\InCycle Software\InRelease\Bin).

You are going to notice that there is a dedicated InRelease section for its parameters. If Release Build is set to True you are going to deploy the build.
You can set a Release Target Stage – if needed. Leaving it blank will make it go through all the possible stages unless stopped - and a specific Configuration to Release – leveraging the same configurations you might use in the Configuration Manager.
Every component must be configured to Build with Application or Build Externally. A Build Independently component won’t work. This is a known limitation of InRelease.
And obviously, both Acceptance Step and Deployment Step of the very first stage of the associated release path must be Automated.
The main task it does is the Configuration File Tokenization. This feature, together with a specific syntax into the configuration files themselves (usually __VALUE__), makes a build-time transformation based on the target stage.

For achieving this, it is needed to install the Client Component of InRelease on the Build Server.
It is not something that hard or trivial – you can integrate these specific tasks into a pre-existing customized Build Template so you are going to get a single template if you need.
After that, the InRelease Release Service is invoked, and everything passes through that, with the related configurations and settings.

Your first InRelease Release

Sun, 01 Sep 2013 14:40:00 +0000

In the previous posts we saw the main pieces of InRelease, so let’s see how they fit together!
You are going to create a new Release: it is based on a Template, and it has two essential information to fill: the Target Stage, which is basically “where to stop” and the build to use, which could be the latest or a selected one (or even a build on-the-run).

You should define the stages, if you didn’t. It is extremely easy, as it just explains who approves the stages and who is the owner. You can add automation (starting a build), if you need.

Releases are fully trackable, and you get a step-by-step progress sequence to check, with its logs.

Team Foundation Server 2013 in production? With some help! TFS Upgrade Weekend

Fri, 30 Aug 2013 22:10:00 +0000

Microsoft scheduled a very interesting initiative for the 13-15 September: the Team Foundation Server 2013 Upgrade Weekend.

What is that? It is a weekend where organizations can upgrade their Team Foundation Servers to the 2013 release with the latest go-live prerelease, and get free support in case of issues by the Microsoft CSS.

I strongly suggest to join us (I am going to upgrade several instances as well, both personal and corporate), to do this you are simply required to register here so they can staff the appropriate people.

If you need to download the previews, here you can find what you might need!

InRelease Components and Release Templates, what are they?

Thu, 22 Aug 2013 09:30:00 +0000

The most important parts of InRelease are Components and Release Templates, which enable deployments to be smooth and automatic.
You can package as a Component almost everything, but everything starts from a build:

You can define to get the Component in several ways: it can be built with the application, independently, or just by picking it up from a file share.
The next step is on defining how to deploy this Component. You must use an InRelease Tool, which could be just your own basic script as you can see.

Beside of that, you can define some variables to be replaced and, most important, the associated Release Templates.
The Release Template is the Release Pipeline’s core. It is built on Windows Workflow Foundation, and it defines the step-by-step deployment activities to be carried on.

Right there you are going to shape every single step with the related configuration variable (like for the Create Web Site activity, for example). You can add as much Components (like Call Center Site) or Activities (which are like Create Web Site) as you want.

Some basic concepts of InRelease

Mon, 12 Aug 2013 07:30:00 +0000

Despite it is tightly integrated with Team Foundation Server, InRelease is – as far as today – a standalone product.
It is formed of three components: a Server, a Client and as many Deployers you might need, installed on the servers where you are going to deploy you application.
Everything is so granular, it reminds of a Russian nested doll.
You are going to create a Release. The Release is based on a Template which defines the stages and the actions of a deployment.

It is based on Windows Workflow Foundation, and it is very intuitive. You can find a huge amount of out-of-the-box actions and the InRelease Components, we are going to see in a separate post what are they and how to customize them.

In order to be able to deploy, the Template must feature Environments, containers for the target Servers running the Deployer component.
In my case, I created two Environments (Development and Production), each containing one server (dev.domain.tld and prod.domain.tld).
As you can see in the picture, for this sample the deployment pipeline is extremely easy: create a folder in the target server and copy some files into it.
Then the simplest release workflow is based on approvals: you must approve the deployment and the successful completion. It is possible to make approvals and rejection from both the Console or the handy web interface.

These are the basic concepts you might need to know about InRelease

Letting System Center Operations Manager 2013 and Team Foundation Server 2013 Preview talk together

Mon, 05 Aug 2013 20:49:00 +0000

Despite TFS 2013 is still a Preview, it is fully compatible with the other Microsoft products.
For enabling the DevOps story, you need to follow the TechNet procedure as usual, but you need:

to install the TFS 2012 Object Model
restart the SCOM HealthService via PowerShell (restart-service HealthService)
after you successfully connect to the server with the wizard, you should get a TF223006 error regarding the command-line tools. Don’t worry. Save the configuration, and manually add the OperationalIssue_11 Work Item Type from the Operations Manager installation media.

and it works!

A little, unnoticed feature in Visual Studio – Notifications Center

Thu, 01 Aug 2013 10:44:00 +0000

It is not something you go around shouting “This is a life changer!”, but IMHO it has its own dignity and it is going to gain more and more importance in the future releases.
I am talking about the Visual Studio Notifications Center. It is something which is based on the Connected IDE, maybe the first example of its integration into Visual Studio, together with the Roaming Settings.
It is a small icon on top of the IDE…

…which opens a Notification pane:

IMHO it is important because it could be the notifications’ hub for informative content (help installation, license expiration) but updates as well.

InRelease and Team Foundation Server, tips for the setup

Sat, 20 Jul 2013 19:46:00 +0000

Recently Microsoft released a preview (non go-live, unfortunately) of InRelease for Team Foundation Server 2013. I am starting to have a look at it, so expect some content in the near future

First of all, the setup. You can even be the most important user in your network, but you would need to use the following command for the installation:

msiexec –I InCycle_InReleasePreview.msi

Otherwise you would get an error.

After successfully completing the installation you could go through some errors. Not too much to worry about anyway, I suggest you to keep an eye on the Windows Event Viewer (for IIS, InRelease uses a 32 bit Application Pool and it can be a trouble in certain environments) and on the logs into C:\ProgramData\

They are pretty useful as they are separed by component, so you would get an error log for the console, one for the server and one for the deployer.

Eventually here you can find a support page with the most common errors and solutions.

Enhancing Agile Portfolio Management experience with Backlog Mapping

Thu, 11 Jul 2013 13:00:00 +0000

Yesterday the Team Foundation Service team released the Sprint 50 build, and one of the features shipped is the Backlog Mapping.

Nothing too big or hard to explain: if you are creating a Portfolio within Team Foundation Service, you would surely get a flat list of Features and a flat list of PBI/User Stories.

With the Backlog Mapping (which is just a pane on the right side), you can drag&drop the PBI you want to be child of a certain Feature, and it is going to be automatically linked.

It is a very nice and effective feature, which combines a strong User Experience with a tangible result.

How the best practice made it into the product: Workspace Mapping in Visual Studio 2013

Wed, 03 Jul 2013 09:29:00 +0000

It is well known that the best practice says “One workspace per project”. Unfortunately it is not always possible to make it as the default solution, for various reasons (typical audience, etc.).

In Visual Studio 2013 the best practice made it into the product: the default Workspace Mapping is exactly one-per-project! In fact if you configure the Workspace for a new Team Project, you are going to get prompted to configure it:

After clicking Configure, you are going to map the Team Project root into a specific folder into your User’s folder:

It is definitely a good improvement, as it prevents the creation of a one, big, monolithic workspace which can take ages to download when needed, with all the related performance problems.

Some tips on adding other levels above the Feature

Tue, 02 Jul 2013 10:59:00 +0000

I know, I know – we have it on the MSDN. But I wanted to take the other route, which is not using witadmin and using the old Visual Studio 2012 with its Power Tools and limiting the raw XML editing to the pure essential part. It went pretty well I have to say. Let’s see…

First of all, download the Process Template you want to add levels above the Feature one (Themes anyone? :)).

When you’re going to open it with Visual Studio, you are going to see that both the Agile and Common Process Settings are empty.

This is because Microsoft changed the structure of the Process Settings, merging everything into a ProcessConfiguration.xml file. No worries anyway, we can fix it.

So, copy and paste the Feature.xml work item, renaming it to Themes.xml, and fixing the WORKITEMTYPE name:

Import it into the Process Template:

Now you can create a new Category using the IDE, and adding the aforementioned Theme. Use Custom.ThemeCategory as a reference name or whatever you may feel right for your custom category:

Now open the Theme.xml file. You have to fix the Implementation Hierarchy. This is very important in order to let you select Features as children.

Now, delete whatever it is not ProcessConfiguration.xml into the \WorkItem Tracking\Process folder, and fix the WorkItems.xml into \WorkItem Tracking:

Now, let’s add a node to the PortfolioBacklogs section of the ProcessConfiguration.xml.

It is enough to copy and paste the Feature’s one, but here it is very important to add parent=”Custom.ThemeCategory” to the existing Feature, in order to keep the linear hierarchy and avoid a “The following element contains an error: PortfolioBacklogs. TF401096: This element defines the hierarchy relationship between portfolio backlogs and must define a linear hierarchy from bottom to top. The specified hierarchy is invalid.” error.

Moreover, add a node to the WorkItemColor section, but remember to follow the existing colour pattern, otherwise the Process Template won’t upload. I used the same colour, but of course you can use others. Just keep in mind the pattern.

That’s all! Now you can upload your Process Template and you’re going to get another level above Feature with all the associated tools (board, etc.)

Hosted Build Servers up to date with Windows 8.1

Wed, 26 Jun 2013 22:45:00 +0000

One of the reasons for using Team Foundation Service and others hosted services is not worrying about technology updates as they are carried on by the provider.

Team Foundation Service is no exception and today, together with the Preview’s release of Visual Studio 2013 and Windows 8.1, the Hosted Build Server got upgraded to Windows 8.1 as well!

But, but. You won’t be able to select them in Visual Studio as a beginning. You have to browse to your Team Foundation Service instance, and enable them for the required project:

Just after doing that you’d be able to select the required Build Controller:

and in the Build Definition itself:

Man forewarned is forearmed :)

Example on what Agile Portfolio Management is covering

Mon, 24 Jun 2013 12:12:00 +0000

I have been asked about a quick example, so let’s take this screenshot:

This is something you can achieve today via Project. But it is not feasible in Team Foundation Server 2012 stating that the “As a customer…” are User Stories. You must use the Project Server integration, setting Project Server and the integration up, it is an expensive process and it is not suitable for everybody.

Here’s why I feel the Agile Portfolio Management is very useful. I understand Project Server is not for everybody, and this new features enable scenarios which were an exclusive of Project Server in the past.

Of course Project Server is not going away, but at least now if you have a well defined scenario you can choose which tool to use.

Basics of Agile Portfolio Management: Themes and Epics

Thu, 13 Jun 2013 08:06:00 +0000

Apart from the technology itself, the introduction of the Agile Portfolio Management in Team Foundation Server and Service has a huge impact on the surface you can cover on your project.

Beware: in most of the cases, I am talking about mid-sized to big projects. Introducing a concept like this in small projects could be counterproductive.

As far as now, the most common way of tackling agile product management is to create some User Stories and then split them into tasks. This is perfectly fine and it is not changing, but sometimes you can face the following problem: the User Story is too big for being delivered in a sprint.

Unfortunately it happens. So to solve this, you have to use the Epic concept.

An Epic is basically a very big User Story, which is split into several sub-Stories whose effort is compatible with the Sprint duration. Think about it as a goal. An Epic contains one or more User Stories, kept together by a common topic. You won’t deliver an Epic in one sprint, usually an Epic is a big part of the product, a (marketable) feature. You manage this on top of the product, as it can impact other products in your organization.

The Theme is on top of everything. Talking in terms of a project, it can be a major release. It is an initiative, one of the cornerstones of the project itself. Themes drive the strategy, and they express a direction – they are generally not too specific because of it.

At the moment in Team Foundation Service (and soon in Team Foundation Server 2013) you’d get the Epic concept out-of-the-box. But as Brian Harry told us in his post, it is possible to customize the experience with a low effort.

A huge leap toward the Agile Portfolio Management

Mon, 03 Jun 2013 14:32:00 +0000

Up to yesterday, managing something more than User Stories and Tasks, Bugs, etc. required a certain degree of abstraction and usage of specific tools like Project Server.

With the newly revealed Agile Portfolio Management feature now we can avoid to use Project Server for doing something which is not designed for, thus we can still integrated it (with TFS 2013) as needed.

Let’s take this example: we want to create a certain system, and one of its features is the Trash Bin. So we create a feature, and I can see it by filtering the Backlog by Features:

This feature has some user stories into it. Let’s say we want to put stuff into the bin and that we want to empty the bin as needed.

These are Product Backlog Items, or Requirements depending on the Process Template you are using. I am using CMMI, so they are requirements – and I change the filter again:

Of course these Requirements are split onto several different tasks, and this is not different since the past. Changing the filter again this is what I see:

This view is exactly what we wanted to achieve. And of course it is way easier to understand and visualize, than using other tools – often not designed for fitting that specific need.

Let’s spread this concept quite a little: can it be handy if you have multiple Scrum teams working on the same backlog? If you have different backlogs (you shouldn’t…) for different teams, why not merging everything on the same backlog in this way? It was hard to explain to some manager how the project was going in term of features and market comparison. Now it isn’t, because you can use the Feature work item type as an abstraction on the work the teams are doing. And it is out-of-the-box, which is never bad.

As Brian said, it is just the beginning…there is surely more to add here.

Team Rooms in Team Foundation Service

Mon, 03 Jun 2013 13:54:00 +0000

So now after the Tech.Ed announcement the Team Rooms are available :)

They are not just a chit-chat tool for conversations into the team. They are an invaluable tool for collaboration.

First of all, we can configure it as a broadcast messenger for certain events

It is possible to tag a certain User Story, or a specific build to talk about.

But the best comes to the specific collaboration tags: @ and #.

The @ tag is for tagging a user:

which is going to get notified about it.

The # tag is for mentioning a specific work item:

After clicking on the hyperlink a new tab is going to be opened with the required work item.

All of this could seem pretty silly, but I can ensure they add some value to the team work, less overwhelmed by emails and better communicating among the members.

Troubleshooting for dummies with Team Foundation Server

Mon, 27 May 2013 20:23:00 +0000

I have been asked how did I manage to understand the issue with the Work Item Synchronization Service I posted before, so maybe a broad answer could be better than a one-to-one.

At the very beginning, I have been notified by a user which didn’t manage to see his Iterations in the proper way after some amendments.

After asking to clean the client cache – an unsuccessful try - I tried refreshing the Data Warehouse, and eventually rebuilding it. No luck again.

When this sort of issues happen, it can be nasty. My suggestion is to avoid running some scripts you may find on the web, as touching the TFS databases without the consent of a Microsoft CSS man would be very dangerous and can put your installation in an unsupported situation or even worse, it can be damaged.

You can have a look in the Event Viewer for issues, it is time consuming but often useful.

Or you can do as I did, logging into the Administrative Page (the informally called _oi) which contains a lot of informations about everything running on the Team Foundation Server, in a almost real time state.

In this case, I noticed the user raised some service calls with –1 as a result, which means error. Opening the log I looked at the error detail, so I managed to get in touch with Microsoft. Luckily the RC of the Update 3 went live shortly after the issue, so applying it was a matter of a very short time.

I strongly suggest looking at _oi very often, as it is not just a troubleshooting tool, but it is a real live look at the servers’ health, with detailed reports etc.

How Developer Operations fit into the Agile picture?

Wed, 22 May 2013 13:34:00 +0000

It looks like one of the buzzwords this year is DevOps.

But what is it? It is the merge of Developer and Operations, which basically means everything that happens while running an application inside the boundaries of the production systems.

It represents a great leap from the standard, reactive way of managing production applications and services on a alert basis, to the new agile, proactive way – which means the Operations teams actively collaborate with the Development teams in order to get better and higher quality products.

The heart of Developer Operations is its principles. They are the incorporation of the Agile development practices in the IT environment, plus a huge enhancement in collaboration which involves Development teams, QA teams (where separated by the Development teams) and Operations teams.

The main tools for achieving this are:

· An automated systems infrastructure, which allows the removal of many of the human interactions and thus points of failure.

· A broad ALM platform, enabling developers to have a shared Version Control System, an automated build server, etc.

· Designing software leveraging on Feature Flags, so that if something is faulty it can be easily disabled while investigating on the issue – without impacting the non-faulty areas of the application itself.

· Continuous Delivery.

· Shared metrics aimed at measuring and improving both the overall and the detailed quality of the application/service.

Of course it is not just about tools. For reaching a good DevOps proficiency every role in the team should collaborate in the proper way from the first inception of the project, in order to have a seamless experience among everybody. DevOps don’t start at the delivery, but at the very first sprint.

Feature flags are a very bright example of this approach. It is a development pattern which directly affects an operations’ topic: configuration. If a team commits to use feature flags in an application involving the DevOps people, the latter must be aware about feature flags themselves and they will know how to proactively manage potential issues.

Everything rely on communication. To get properly working Developer Operations the Ops team must be open to a huge mind shift – from stability to agility, as the change referred here is not a breaking change but an evolutionary change, often required by the business itself. The existing boundaries between Development teams and Operations teams should be removed, with their disruptive behaviors.

The natural evolution of Developer Operations would be the Agile Operations – the Operations team would then use some of the core Agile principles (Kanban or Scrum derived, like backlogs) together with some specific developer tools like a Version Control and a Build Server for their own deployment efforts.

This second step of course needs a lot of prerequisites – as opposite as the Developer Operations one which is pretty easy to start – but benefits would be huge. Concepts like the Daily Scrum applied to an Operations environment empower productivity because of the direct communication flow happening beneath.

So, answering the title: How Developer Operations fit into the Agile picture? By incorporating the Agile development lifecycle, applying concepts and principles from the methodologies (usually Scrum) to a completely different topic – Production Operations.

Migrating distributed branches from Git to Team Foundation Server

Tue, 14 May 2013 15:13:00 +0000

If you have to migrate (like me, today) a huge Git repository to Team Foundation Server, it’s very likely that you are going to hit one of the most common walls while migrating a distributed VCS to a centralized one: understanding the branches’ lifecycle.

Briefly, in a DVCS you won’t have the common branches you might find in a VCS like Team Foundation Server, because of the nature of the DVCS itself which tends to have a number of branches for making offline working easier and smoother. Of course you won’t be able to clone this structure inside the Team Foundation Version Control, but there is a way to mitigate it.

I am using Git-Tf, the Microsoft’s tool for migrating Git to Team Foundation Server. After you configured your repository, you should perform a git-tf checkin –deep in order to replicate every single changeset instead of a big bulk one. But you’d get an error:

Here is what I meant: if you have multiple parents for a commit, you cannot replicate it inside Team Foundation Server. If you rebase, you are going to edit the history, which is wrong from a preservation point of view.

So you should use the –autosquash switch, which is going to create a linear history without editing it. How? By finding out the HEAD revisions.

Work Item Synchronization issue with Update 2

Wed, 08 May 2013 09:00:00 +0000

After installing the Team Foundation Server 2012 Update 2 it can happen that the Work Item Tracking Synchronization Service suddenly stops working, so that you can’t see updated areas and iterations neither in Visual Studio, Web Access, Excel, etc.

These are the symptoms…

To help us troubleshooting this nasty – but known – bug, the _oi Activity Logs are very helpful…

We see that from a certain point, a number of Work Item Tracking Integration Synchronization jobs are failing…

…and the Job History Details show a System.NullReferenceException. Here is the problem!

The Team Foundation Server 2012 Update 3 contains a fix for this, as detailed into the changelog (see the Work Item Tracking paragraph into the Team Foundation Server fixes).

Behind the scenes of the Work Items’ states: Team Foundation Server Metastates

Wed, 24 Apr 2013 15:15:00 +0000

Despite present since the RTM version, the metastates became notorious to the mainstream after the introduction of the Kanban Board. Why? Let’s see…

New, Approved, Committed and Done are metastates. Have you ever heard about them before? I don’t think so J

They are not something particular, but just an aggregator of various states for Work Item Types. Metastates are defined into the Process Template of course, in our case just for the Product Backlog Item Work Items:

As we see, we can have a Proposed (state) Work Item which can be either New or Approved.

This is the easiest sample, you can customize the board to show more metastates, you can report against them, and much more.

Web Access Licensing for dummies

Wed, 24 Apr 2013 15:12:00 +0000

With Team Foundation Server 2012 the licensing became way easier, in order to have a clearer path of adoption for the involved features. One big example of that is the new Web Access.

The new Team Web Access now features three levels of information access, dependent on the CAL you have:

These three levels exposes a different set of information to the user.

A user acceding the Web Access with a Limited Access level is roughly the same as the old Work Item Only View in Team System Web Access, so the user can access to what belongs to him without the need of a CAL.

The Standard level is for who has access to Visual Studio 2012 Professional, and it adds all the standard Web Access features plus the Agile Boards introduced with the 2012 release.

The Full level is for who has access to Visual Studio 2012 Premium and above, it enables every feature of the Web Access, so the Backlog Management Tools, the Feedback Management and – with the Update 2 – the Web Test Case Management.

A clarification on the Team Foundation Server Integration Platform support

Sun, 14 Apr 2013 14:41:00 +0000

Often many people think that as the Team Foundation Server Integration Platform is an open-source project, it has no support.

WRONG!

It is the only Microsoft supported solution for all the migration needs you might have.
But only if you download the Visual Studio Gallery package, which is the stable and supported version. If you have an issue with it, you can raise a call to the Customer Support Service.

If you download the Codeplex package (with the source code), you might get the betas, which are obviously not supported.

I hope this clarifies a bit around this really important topic

Solving mess on behalf of others: tf undo

Tue, 09 Apr 2013 11:36:00 +0000

Sometimes it happens the TFS Administrator has to solve problems caused by unexperienced (or untrained) users, and maybe the most common is to undo ‘ghost check-outs’.
Here’s the answer: Attrice Corporation Team Foundation Sidekicks. Cool. But sometimes you can’t use third-party tools, and you only have to rely on what Microsoft provided in the OOB installation.

So here’s the real answer, since Team Foundation Server 2005: fire the Developer Command Prompt, and launch the tf undo command with the proper switches.

Here there is the relative documentation.

DevOps 101: IntelliTrace to the rescue

Sat, 30 Mar 2013 20:29:00 +0000

We have seen how to fix the gap between development and operation teams in a quick&dirty way. There is a lot more to do, and tons of tools which can help us: the main one is IntelliTrace.
When we create an Operational Issue, an IntelliTrace log is attached to the work item itself:

but it features just the minimum subset of information related to the alert.
The first way would be manually get a .iTrace file with our custom collector. Nothing that difficult, but if the main motto of DevOps is “automate everything”, we are going against it.
Or – way better – I can ask the Ops folks to record a detailed IntelliTrace log, of course everything integrated with Team Foundation Server. It’s just needed to set the work item to “awaiting evidence” with a resolution note telling them to provide me a better IntelliTrace log:

Then the Ops guy is going to use the IntelliTrace Tasks tab to gather what Engineering wants. Definitely easy!

He can collect a snapshot of the current state of the involved application pool, or better he can start collecting a new IntelliTrace file, replicating/let someone replicate the scenario on behalf of the user, and then the new IntelliTrace file is going to be attached to the related Work Item.
All the IntelliTrace files are going to be stored into a network share, one folder for each alert, so remember to keep an eye on the storage size!

DevOps 101: Managing Operational Issues

Wed, 20 Mar 2013 14:15:00 +0000

As we’ve seen, once Operations send to Engineering issues, they are just Team Foundation Server’s Work Items.

This specific Work Item Type is tailored on the need of explaining a production incident, probably a bug, so it features several useful information out-of-the-box. It’s tied to the AVICode informations, and the most important thing here is the state:

After we acknowledge we are on the Issue itself, we have a broad range of states to be set: this is essential for organizations with a structured process (think about ITIL).

Apart from that, it’s a standard WIT, so there is not so much to say on the Engineering side. Hey, we are who were already working with Team Foundation Server!

There is an IntelliTrace file too, as mentioned. In the next post we are going to see how to better capture all the information we need.

DevOps 101: from production errors (ouch!) to Engineering

Sat, 16 Mar 2013 14:31:00 +0000

I decided to name this series after the classic introductive American class: 101. We are talking about DevOps (with Visual Studio ALM 2012), so DevOps 101

KABOOM!
The first step toward Developer Operations is allowing production errors to get intercepted and stored into Work Item Types for the Engineering team. As we saw in the last post, there is a new, dedicated WIT for that: Operational Issue.
Once we hit a bug in production, one (or more, depending on what caused the error) alert is raised. This alert can be sent via email, too, in order to trigger both a formal (via the SCOM Console) and informal (via email) communication.

It’s not just a simple ‘alert’: it features all the information we are going to push to the Operational Issue.

Once we modify the status to Assigned to Engineering, it is pushed. Aside from all the tabs (it wouldn’t be a 101 post otherwise ) let’s have a look at the Alert Description box. It features an hyperlink to an URL which uses port 45451. What’s that?!

It’s the result of the Microsoft’s acquisition of AVICode. A full-featured application monitoring system has been integrated inside SCOM, and the information it gathers are rendered by this service, capturing every kind of stuff you can think at the surface level.
Beware: an IntelliTrace file is added to the work item, but it’s not that huge. We are going to see in a separate post why, and how to integrate IntelliTrace in our DevOps workflow.
The next post is going to the other side, so what happens in Engineering when a Operational Issue is raised in Team Foundation Server. Stay tuned

Basics on Developer Operations with Team Foundation Server 2012

Fri, 08 Mar 2013 11:01:00 +0000

As we saw in the last post, the DevOps movement is making so much noise in the IT world and of course Team Foundation Server is not behind: here is the basics on the integration with System Center Operations Manager in order to integrate the two worlds.

First of all, we need to set the server and the Team Project Collection for the application we want to monitor:

Then we can set the Projects where the new Work Item Type – Operational Issues – are going to be stored. We can set the appropriate Area Path.

Apart from the connection between SCOM and TFS, a huge aid in bridging Operations to Engineering is brought by Alerts. Whenever the state of a Operational Issue changes, an alert is triggered for the Operations administrator:

Then we have a dashboard recapping all the information we entered. I highlighted the possibility of importing Operational Issue work items: this is really important when it comes to consolidation, an often under considered topic.

UK, here I come!

Thu, 28 Feb 2013 11:19:00 +0000

As somebody knows, I am going to relocate in a few weeks in the United Kingdom. It’s a dream I had since I was a child, which now becomes true

I am going to relocate in Taunton, Somerset – working for Quest Software (acquired by Dell in September 2012) as a Team Foundation Server Administrator for their Visual Studio ALM platform. It’s not only that, but for some more details I have to start working for them around five weeks to go, though.

But the fun is not over: with the relocation I also have to change my country as a MVP. So I am going to be a UK MVP, and I am surely going to have the pleasure of working with Richard Fennell, Mike Fourie, all the other UK & Ireland MVPs and my new MVP Lead Claire Smyth!

So, now I only have to complete the toughest part of the job: packing everything and doing the move! And the best is yet to come

What’s all this noise around Developer Operations?

Sun, 24 Feb 2013 21:24:00 +0000

During the last months a huge movement is gaining more and more importance in the IT world: the DevOps one.

What we usually covered until now is the Define-Develop side of the process. We never went deep on Operate, as “these are tasks for IT guys”. Release Management is another sample of it, but we are going to cover it separately.

But as we are living in a dynamic world, things change. Microsoft started a vision of that (from the IT side to be sincere, but still a vision) in 2007. Did we get there? Not really, but so far so good.

In the picture I highlighted some of the most common issues, which almost everybody went through at least once in their career.

Non consistent tool

Is there a ‘standard’ –read ‘mainstream’ operations backlog management tool, integrated with the Engineering side? Never heard of. Almost every organization has a tool, but it is often custom, standalone and rarely integrated with the developers’ systems.

Production incidents hard to debug and resolve

Sometimes bugs happen because of production-only issues. The VS2010 momentum of “no more no-repro” was the first leap toward solving this problem, but now we need something more.

No Knowledge Base management

This is like the ‘non consistent tool’ one, but worse as almost nobody (I would say less than 25% of the companies I worked with and upon) do that.

Can’t get actionable feedback

Linked to the one on production incidents, getting actionable feedbacks is quite hard as far as now. So it’s definitely needed an improvement in this area.

There is a lot to fill the gap, as possibilities are almost endless. And there is still a lot in place, think about Lab Management and its end-to-end workflows. This is a sample of an integrated Release Management with Developer Operations, for stuff up to the QA stage. We now need to go further.

With Visual Studio 2012 we finally got the possibility of bringing all the needed information in a seamless way from production back to engineering, as we are going to see in the next posts, trying to close the gap it exists in there.

Some insights on it? SCOM, TFS, IntelliTrace. Stay tuned

ALM Summit sessions are out!

Tue, 19 Feb 2013 16:13:00 +0000

I have just been notified that all the ALM Summit content has been delivered

You can find the slide decks here, and the videos hosted on Channel 9. These are great content for ALM with tons of useful information!

Web Test Case Management in Team Foundation Service

Wed, 13 Feb 2013 20:11:00 +0000

Again, after the announcement at the the ALM Summit, I am covering one of the new features introduced with the release of the CTP of Update 2, which is going to add these on-premise, but if you are a Team Foundation Service user the update has already been enabled by setting the right feature flag

Enabling Test Case Management on the cloud is not just a matter of technology. As you can imagine, it opens up a broad range of possibilities for testing, because you’re not that deeply tied to Test Manager for the QA tasks but you can freely use the web interface.

You can find it under the new TEST hub in the web UI: and it enables you to interact with existing test plans.

I can add test cases just like in MTM!

Please notice: these test cases are already integrated with the new Tags system.

Then I can run my test cases, a side window opens just like in MTM:

As you could see, the whole execution lifecycle is now accessible via web. Think about this scenario: you have to test a piece of code you run on a HP Supedome [HP-UX so, a mainframe] and you obviously can’t install MTM on it. The user doesn’t know MTM and doesn’t need it, as Web TCM solves this and not only, of course.

Review – Professional Team Foundation Server 2012

Tue, 05 Feb 2013 09:38:00 +0000

We went through a general overview of the platform, a detailed deep dive on the client, it’s now time for the server part of Visual Studio ALM: Team Foundation Server.

This book is considered as ‘the Bible’ for everyone who deals with Team Foundation Server. It covers in details everything you have to know and everything you should know about it.

Why did I say that? “have to know” and “should know”?

The reason is fairly easy: the book is not just a compendium of documentation, how-tos, etc., but it empowers direct experience from the field. So the authors (Ed Blankenship – Program Manager for Test and Lab Management, Martin Woodward – Program Manager for Team Foundation Server cross-platform tools, Grant Holliday – Senior Premier Field Engineer and Brian Keller – Principal Technical Evangelist for Visual Studio ALM) shared the knowledge they got from years of experience, in order to provide the most complete book on the topic.

The table of content is pretty straightforward: it covers from the deployment planning to the administration and all the maintenance activities, 27 chapters in total.

As a sample of the direct experience from the field I was mentioning before, it is worth a look at the chapter regarding the deployment planning: there you can find even a basic estimation on times, really useful if you are not into the product and you need to have a rough order of magnitude on the required effort.

It’s still a great purchase, even if you already have the 2010 version. The book has been updated with all the new stuff of the 2012 release, and it’s worth having it if you work with Team Foundation Server in a role which is not the ‘end user’.

Tags in Team Foundation Service work items

Wed, 30 Jan 2013 17:08:00 +0000

At the ALM summit it has been announced that a tag system is now supported on Team Foundation Service.
What does that mean? Well, that’s really easy J

I can now add simple tags to my tasks, PBI, etc:

Just inserting text into it:

As it’s a column in the Work Item Type, you can filter for them:

And here we are!

You have to remember it’s a first release, and as the Team Foundation Service delivery model is based on Continuous Delivery, we can expect further improvements and new features added soon.

MCSD:ALM – WTF?

Tue, 29 Jan 2013 20:41:00 +0000

Despite it can sound like a really complex acronym this is the new certification launched today at the ALM Summit, purposely baked for Application Lifecycle Management.

It’s made up of three exams: the 70-496 (Administering Microsoft Visual Studio Team Foundation Server 2012) is the first one you should approach, because it’s the most generic one on Team Foundation Server and it covers all the basis for an efficient administration of the platform.

The second one is the 70-497 (Software Testing with Visual Studio 2012), and it’s focused on the testing capabilities of the platform. So it is going to cover Test Manager, planning of test cases and correct management of them, analysis of results, etc.

The last one is the – guess what? – 70-498 (Delivering Continuous Value with Visual Studio 2012 Application Lifecycle Management), covering an effective definition of a end to end SDLC, and then expanding it to the whole ALM – for instance. Then Quality, and Operations.

As for all the new certifications, a recertification must be taken after two years from the completion.

400 characters path limit in Team Foundation Server 2012

Thu, 24 Jan 2013 08:25:00 +0000

This is a brief post to answer a simple question.

“I have been told Team Foundation Server 2012 supports paths longer than 260 chars. How is it possible? How can I manage it?”

Simple question, simple answer: if you have to work on a specific branch, which goes over the limit (eg.: $/Project/SubProject/Branch/…./WhatINeed, over 260 chars) you just have to map it to a shorter local path.

Rationale behind it? This is a needed change in cases we have a huge branching strategy in place, sometimes inherited from migrations of older projects. It impacts just the server, not the clients, so you are still subject to the Windows limit.

git-tf, linking the Distributed and the Centralized worlds

Mon, 14 Jan 2013 08:15:00 +0000

Recently Microsoft released a new open source project, aimed at all these developers who would rather avoid to use Team Foundation Server but they must do so – for several reasons – instead of using Git.

Then it came out git-tf: a bridge for using Git as a local repostitory, after which every commit can be merged as Team Foundation Server changesets.

After you set a local repository up (git init), I suggest you to copy the git-tf files over there. Then you have to bind the local repository to the Server and the Team Project:

Once you’ve done this, you can start adding/modifying the involved files. As a sample, I added a file into the local repo and I committed the file:

We’re only missing the check-in

and here we are!

This is the first step toward the Distributed Version Control System from Microsoft It still misses some features, but from version 2.0 (so the latest) on it is a feasible way of letting everybody use what they want inside the company

What’s the difference between the Backlog Board and the Kanban Board?

Sun, 06 Jan 2013 21:17:00 +0000

As you know, in one of the latest Team Foundation Service deployments (I recall it, the team works on a three-weeks-long sprint) and soon to be in the Quarterly Update 1 for Team Foundation Server, there has been a nice new feature: the Kanban Board.

Kanban is a process based on the boundaries imposed by the work-in-progress limits. Everything is in a queue, with defined states (eg. Development Ready, Test Ready, Release Ready, etc.), and the to-do jobs are governed by the capacity of the team. Ideally, this is the best way for ‘just in time’ production

It has a fairly interesting history, as it’s been created by a Japanese man watching american stocking habits in supermarkets. More on Wikipedia.

Kanban forces the team to rely on their self-control, continuously adjusting their queue based on the work they can do. Using it together with Scrum – for instance, inside the sprints – makes software development like a Swiss clock. That is my opinion, of course

How does that fit in Team Foundation Service? The Kanban Board is the main tool for adopting Kanban: it’s visual, and effective.

In our case, it doesn’t affect the existing Backlog Board, they are complementary! Here’s what I mean:

This is a sample Backlog Board: I can see on the left my PBIs, with the inner tasks composing it, and their status.

Here is the correspondent Kanban Board on the same project:

I can just see the User Stories, and not the linked Work Items. And as I am the only project member, I entered 1 as the maximum WIP load. So I can understand just looking at it that I am overcommitted.

So the Backlog Board can be used to understand a finer grain load, at a task level, for my team. The Kanban Board is a useful tool for a project level inspection. They are two different tool but they might be used together

Back to back, to back, to back!

Wed, 02 Jan 2013 13:01:00 +0000

Great news for this year: I have been awarded for the 4th time in a row (here’s the title ) as a Microsoft MVP for Visual Studio ALM.

So you can expect a new, great year of content around ALM, Team Foundation Server and Visual Studio.

And I am really happy to be still part of the family.

Review – Professional Visual Studio 2012

Sat, 15 Dec 2012 10:11:00 +0000

This heavy, 1054 pages book is the reference for every developer approaching Visual Studio 2012.

If the review would be just one sentence long, this would be my review but it isn’t, so here’s the thoughts: the book is huge, wrote by Bruce Johnson (Visual C# MVP) and provides an analytic insight inside the new Microsoft IDE.

As it is focused on the IDE itself, it doesn’t do deep dives on ASP.NET MVC or WPF, just to say, but it provides some technology samples to quickly start up beginners. Every tech sample is in both VB and C#.

You might think it’s just for beginners: that’s wrong. It’s a deep dive on the IDE feature set, and it’s not targeted at providing code apart from the related one. It’s useful as well for experienced developers.

A notable example: the Visual Studio Extensibility chapter is really complete and provides several samples regarding the model, guiding step-by-step the reader from the bottom-up.

Completing the field, the book provides some separate chapters for Visual Studio Ultimate and its exclusive features, and Team Foundation Server, making them fit inside the Microsoft’s ALM family of products.

I really liked it, and I strongly suggest it to all the developers working with Visual Studio 2012.

Workspace Templates: a useful helper for non-VS users

Tue, 11 Dec 2012 08:47:00 +0000

If you have a user which doesn’t use Visual Studio (reasons may vary: designers, stakeholders, analysts, etc.) but uses the Windows Explorer Integration brought you by the Team Foundation Server Power Tools, this user must go through the Team Explorer at least for setting the workspace.

Letting them use the Team Explorer is a shocking experience, from a users’ point of view: they are not used to the complexity of Visual Studio, and this can lead to errors and problems.

In order to fix that, we can use the tf workspace command-line tool, with the /template switch.

It’s extremely easy:

tf workspace /new /template:myworkspace;TFSAdmin /collection:http://server:8080/tfs/Collection

It takes a myworkspace linked to the user (in my case, TFSAdmin) and it creates for the current user a copy of it. So the project is already mapped, and the user can start using the Windows Explorer Integration alone.

Batched Gated Check-ins

Mon, 03 Dec 2012 08:45:00 +0000

A subtle new feature in Team Build 2012 is the possibility of batching the gated check-ins workflow, which enables you to “sum up” your check-ins and let the Team Build elaborate them together.

It’s available under the Gated Check-in trigger in the Build Definition configuration:

Then, what happens if one of the queued builds fail? No problem, they are going to be sequentially reinitialized and individually elaborated, in order to avoid further problems.

It’s a feature which finds its fit just inside big teams, I admit it…but it can still be useful even in other scenarios.

Review - Visual Studio Team Foundation Server 2012: Adopting Agile Software Practices: From Backlog to Continuous Feedback

Fri, 23 Nov 2012 21:27:00 +0000

This book, wrote by Sam Guckenheimer (Product Owner for the Visual Studio ALM family) and Neno Loje (Microsoft MVP for Visual Studio ALM) is a complete, five star journey into the world of Agile Software Development.

After introducing the Agile Consensus and what rounds around it, the book covers all the basis for the Product Ownership, and details how every sprint should be managed. The first section is not just for beginners: there are concepts which even after a years-long seniorship, could be hard to fully understand. Do not underestimate how these concepts might be similar but different: after these the destiny of your project can be strictly dependent.

Then we have a chapter for everyone of the four classic pillars of Software Development, using Team Foundation Server: Architecture, Development, Build and Lab, Test. But do not expect anything ‘classic’ here: the content is extremely fit to the topic of the book, and it’s really comprehensive.

The last two chapters are not product or methodology focused: one is about the lesson learned at Microsoft – inside the Developer Division – and believe me, every word is worth of notice because it clearly explains what happens in a huge division like DevDiv, and what are issues and stop factors you might find in a real world scenario like that.

The other is on how to integrate the Continuous Feedback inside the usual workflow of the team, not technology focused but more on the theoretical side of the problem.

The target is pretty clear - Product Owners, Scrum Masters – but, again, not just for beginners: concepts explained here are not just Visual Studio ALM tied or step-by-step tutorials, they are just declined on the product, but agnostic on their side.

The book has lots in common with the previous release, it’s normal as it’s on methodologies and practices, but it has been broadly update for Visual Studio 2012 – so don’t expect a mere copy&paste. In the end, it’s a great resource for people working with planning, prioritizations and code quality.

Candidate Changes with Local Workspaces

Fri, 16 Nov 2012 22:50:00 +0000

As with the Local Workspaces we can work offline in a easier way than before, there’s another really useful side-effect of this: the so-called Candidate Changes.

When we add a file or delete something outside Visual Studio (in Windows Explorer for instance), regardless of the connection to the Team Foundation Server, it recognizes there’s something different:

Those changes are not included by default, as it was not an action done with Visual Studio, so another confirmation is required – I tried deleting the Program.cs file:

If I rename a file, it’s like every file renaming in Visual Studio: a delete followed by a add operation. If I select both, it can understand it and treat these two operations as a rename – in my case I renamed the App.config file to Appfile.config:

It’s a really powerful feature, both with and without connection to the Team Foundation Server, which allows us to keep tidy our operations outside Visual Studio (but not including those made with the Windows Explorer Shell Extension of the PowerTools).

Visual SourceSafe Upgrade to Team Foundation Server, the new way

Fri, 09 Nov 2012 16:22:00 +0000

Some minutes ago the Visual SourceSafe tool for migration to Team Foundation Server and Team Foundation Service. It is already available inside your Team Foundation Administration Console or from the Visual Studio Gallery. Beware, it requires a reboot of the server.

The installation is pretty straightforward: next next finish

After you launch it, it’s going to ask you for what repository you are going to use, and which projects you’d like to migrate. You have to manually use Analyze, before of doing so. And you may select just some projects, if needed:

After this you have to select the destination for the Team Project…

…and the SQL Server to use as a storage, together with the migration type, full or tip:

At the end of the migration the tool is going to provide you a report like the one you were used with vssconverter.

Inside the MSDN library you can find the documentation about it, which is pretty comprehensive and includes how to use the command-line VSSUpgrade – the underlying command line tool you can use when you need to automate the migration or in some borderline cases (like when you have a huge database and you want to prevent errors caused by network connectivity disruption) – and the most common troubleshooting operations.

Review - Professional Application Lifecycle Management with Visual Studio 2012

Fri, 02 Nov 2012 16:33:00 +0000

If you have to start approaching the Application Lifecycle Management, this is going to be your bible.

Written by Mickey Gousset (Visual Studio ALM MVP), Brian Keller (Microsoft Senior Developer Evangelist ), Martin Woodward (Microsoft Program Manager for Team Foundation Server) the book starts with a six-chapters-long introduction to Team Foundation Server, describing in detail what’s this mystical object and how it can be useful for us That’s different from the 2010 version, but I really like it because it enables the reader to fully understand the platform, instead on focusing on a series of tools and practices. It’s detailed but introductive, perfect for the target audience.

After that, it describes how to gather feedbacks from stakeholders, and how to let them participate in the requirements management phase.

The Project Management section is comprehensive, rounding from Work Items to Dashboards, describing all the tools involved in a complete ALM process. It’s not just about the tools and how to use them, several pages are dedicated to process and methodologies, making it a manual in the manual for Project Management with Team Foundation Server.

After these first three parts, the following are more code-focused: Architecture, Software Development and Testing. They fully cover the new features but always with the process companion. Really useful for both novice and experienced people who might want to have a reference.

Despite it has the same title of the 2010 version, several parts have been redone both after feedbacks and to have a different approach. I really liked this book, it’s a must-have for everyone.

Upgrading Team Foundation 2012 Express

Thu, 01 Nov 2012 08:12:00 +0000

It can happen that you have to migrate from a TFS Express installation (reasons can be various) to a full featured one.

It’s pretty easy: as the Team Foundation Server database is the same regardless of the edition installed, it’s just a matter of upgrading the Application Tier in order to enable all the missing features.

The first thing to do is to uninstall Team Foundation Server Express if you’re doing an in-place upgrade, otherwise the installer is going to notify it to you:

Then, after the Team Foundation Server installation (again, in case of an in-place upgrade, otherwise after attaching the databases), the only required step is the Application-Tier Only procedure inside the Wizard.

After the Welcome screen, we just have to select the database instance and list the resident databases:

So we have to select the Service Account, in order to run the services:

Then we review the configuration…

…and scan for the readiness:

After clicking Configure, the Application Tier is going to be added and your database are going to be fully functional.

Team Foundation Service is RTM!

Wed, 31 Oct 2012 17:07:00 +0000

Today at //Build Microsoft unveiled what a lot of people was waiting for: the RTM of Team Foundation Service.

You can reach it at http://tfs.visualstudio.com/, despite the old http://tfspreview.com will still work for some time. Billing is still not active, but now we know somewhat more over it

Here’s what you were waiting for: as promised, there’s still a free level of service.

It’s going to be free for team up to five users, with no feature limits!

And moreover, who has a MSDN Premium, Test Professional or Ultimate is entitled to have an unlimited subscription included inside his MSDN!

There’s going to be a paid service with unlimited users for who has not a MSDN Subscription but it’s still early to talk about that.

The only Team Foundation Service component still in beta is the Hosted Team Build.

Marking transactions on Team Foundation Server’s databases

Mon, 22 Oct 2012 19:50:00 +0000

As we know, in the Team Foundation Server PowerTools for the 2010 version and built-in in the 2012 version we have a Backup&Restore utility which is added to the Administration console for…backup purposes J

But it’s not always feasible: in some organization this kind of tooling could not be allowed, and therefore we have to follow the old manual procedure documented in MSDN.

It’s a little bit tedious, as it’s fully manual and we have to repeat this for each database in our Team Foundation Server deployment, so it can be error-prone, and during troubleshooting sessions it can lead to issues.

So, in order to minimize this, there’s a useful step to follow to track down all the transactions on the TFS’ databases: the transaction table.

It’s fairly easy: we have to create an empty table in each database, using the following script:

   1:  Use TFS_Configuration

   2:  Create Table Tbl_TransactionLogMark

   3:  (

   4:   logmark int

   5:  )

   6:  GO

   7:  Insert into Tbl_TransactionLogMark (logmark) Values (1)

   8:  GO

After that, we can create a Stored Procedure which marks every transaction on the TFS’ databases, and reports back to the table:

   1:  Create PROCEDURE sp_SetTransactionLogMark

   2:  @name nvarchar (128)

   3:  AS

   4:  BEGIN TRANSACTION @name WITH MARK

   5:  UPDATE TFS_Configuration.dbo.Tbl_TransactionLogMark SET logmark = 1

   6:  COMMIT TRANSACTION

   7:  GO

Then you can run the Stored Procedure, and mark the transactions with a mark. As MSDN states, “TFSMark”.

   1:  EXEC sp_SetTransactionLogMarkAll 'TFSMark'

   2:  GO

So you can automate this Stored Procedure, and use it as a ‘filtered log’ on your database activities.

It’s nothing new in the end, but as it’s hidden inside the MSDN documentation I’ve never seen it out there, and IMHO it was worth of a mention.

Rollback Changeset in Team Foundation Server: the time machine

Wed, 10 Oct 2012 19:26:00 +0000

It may happen you have the need of rolling back a previous changeset (due to various reasons). As far as today, you could do it with Get Latest Version – compare – Merge&Fix. Fairly rough, and not intuitive.

To be honest, this feature existed since Team Foundation Server 2010. It was just tf rollback, and no GUI was provided.

Then the PowerTools integrated it with Visual Studio, but now it has been promoted as a first class feature in Visual Studio 2012.

The time machine (as I called it) works as following:

Then you get it inside the Pending Changes, and you only have to check it in the Team Foundation Server. It’s possible to rollback even selected changesets, ranges, etc.

Random questions I got on Team Foundation Service

Wed, 03 Oct 2012 11:48:00 +0000

During the last months I went back and forth demoing Team Foundation Service, and several questions came up. Despite there’s a FAQ page out there, it seems people don’t read corporate pages , so I decided of putting them all together in this page.

Am I tied to Windows Live for my users? Can I use Office365 or corporate accounts?
The answer is not yet. The Team Foundation Service authentication relies on Windows Azure ACS, so it’s technically possible to federate users or use corporate accounts but at this time (October 2012) it is not an enabled scenario, and you still have to rely on Windows Live for authentication. Nothing prevents you to make your corporate accounts Windows Live IDs, just signing up with the Use an existing account option.

Are upgrades managed by Microsoft? Which version of Team Foundation Server do I get signing up on tfspreview.com?
The Microsoft’s approach on this is pretty clear. The hosted version is going to be always the most recent version on the market, as Brian Harry pointed out on his blog. The Team Foundation Service team works on a three weeks-long sprint, and delivers straight to the service, so you won’t have to wait for Service Packs or Cumulative Updates. Moreover, tfspreview is not subjected to the Patch Tuesday, as critical patches are applied daily if needed.

What about my data? I don’t trust Microsoft to be the hoster of my source code!
Despite you won’t be attracted by Microsoft’s policies and behavior, they are never going to read your data. It’s clearly written in the EULA you accept when you sign up for the service, they can just move your data for backup and high availability purposes, but they are not able to see what’s inside their databases. It’s a legal agreement, and because of this it’s not meant to be interpreted. It’s as it, period.

What about my data? I want to be able to move away from Team Foundation Service whenever I want!
Again, your data is your data. But remember tfspreview is…a preview and so not feature-complete at the moment. Maybe the top priority now for Microsoft is to enable you to easily export your data. Meanwhile, you can always sync it to your on-premise instance of Team Foundation Service via the Integration Platform.

How expensive is the service going to be? How much is it going to cost?
In the Pricing page of tfspreview.com it’s clearly stated that there’s going to be a free level of service. We still don’t know what does that mean (in terms of features), but it’s a fact.

These are just the five most common questions I got during these months. For a more complete set of answers, I suggest to go to tfspreview.com you’re going to find all you need there.

Team Alerts as an automated notification tool

Fri, 21 Sep 2012 05:57:00 +0000

Communication among team members is the main pillar for the modern ALM, no excuses.

There are many ways of getting all the team members involved, but sometimes a communication needs to be asynchronous and, more importantly, automated.

Here’s our help: the Team Alerts.

Alerts are customizable on a user basis, but with the new Team concept of Visual Studio ALM, we get Team Alerts. This alerts can be sent when a specific event happen, to a list of users.

In my case, I created a “Test Build Team”, which contains just one user (me J) and it is obviously nested inside the main project team. In a real world scenario, this is supposed to contain all the users whose job is to manage the build.

After that, I can configure a new Team Alert, just for the Test Build Team (when a build fails, it’s triggered)

Then notice some details: thesubscriber is the whole team:

The alert is generated upon a query:

And the alert is sent to the email address of the whole team (so it can be a DL, for instance):

Understanding user loads with the Team Members tab

Wed, 12 Sep 2012 07:39:00 +0000

With the new wave of Visual Studio tooling for Project Management, I’ve been asked for a quick way of understanding commitment of the developers as a high level overview.

There are lots of ways doing so, but IMHO the quickest is the following: the Team Members tab in the Board.

Look at that:

In order to get a full picture I had to zoom it out. It’s pretty messy, and it’s good it is, but it’s not that useful…

So clicking on the team members tab, gives us a pretty comprehensive table:

This is definitely more readable than understanding a full taskboard on the run.

Remote UAC with Standard Environment and Workgroup Machines

Sun, 02 Sep 2012 17:19:00 +0000

As using workgroup machines in Standard Environment is a borderline scenario, there are some issues and stuff to care about, like the careful usage of shadow accounts or the right management of Remote UAC.

In certain scenarios, having Remote UAC enabled may lead to wrong or misleading behaviors, as basically it doesn’t leases a admin token but (correctly, from a security perspective) just a limited one.

For example, the automated installation of the test agent inside a workgroup machine from another workgroup machine running MTM would fail, as this is a scenario where authentication and authorization (two different concept as we know). To workaround this and other cases, the solution is pretty simple. The only need is to set the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system\LocalAccountTokenFilterPolicy key to 1.

This procedure is totally supported, as it’s stated inside this MSDN page on Test Controller configuration.

Beware of the Microsoft Account!

Mon, 20 Aug 2012 13:48:00 +0000

The introduction of the Microsoft Account as an identification method on Windows 8 is great, it enables several scenarios in a seamless way and it makes life easy for users.

But there’s a downside over there: some services won’t work as the required impersonation (there’s always going to be a “shadow user” of your Microsoft Accounton your pc) is not allowed to be done from a security perspective.

This leads to problems in particular with Visual Studio Team Lab Management, where a massive usage of the impersonation is done in order to use the Lab features.

In my case, I verified tons of troubles when, with a Standard Environment made of workgroup machines. In this case, the installation of the required agents inside the machines always failed, with no particular reason (and without a real error!):

Obviously I don’t want to manually install anything, so the solution is to use another Windows Account (warning: a local Windows Account) as the Lab Service Account:

That’s it

Tailor-made Visual Studio 2012 installations (aka unattended, the new way)

Fri, 17 Aug 2012 09:15:00 +0000

Up to Visual Studio 2010 the unattended installation was made up of many steps, making a journey into a .ini file…

With Visual Studio 2012, the new experience is pretty faster, cleaner and easier.

The first thing to do is to create a Network Image, to be used into the company to deploy Visual Studio 2012. You have to create a X:/IDEinstall folder.

Then the only needed step is to customize the AdminDeployment.xml file! I won’t go deep dive on the schema as the MSDN documentation is self-explanative, but it can be summarized as it: you can choose which component to install in a Yes|No binary choice.

Once the AdminDeployment.xml file is customized as you want, you just have to grant the share all the required permissions and the users are automatically going to install Visual Studio with the defined settings.

Otherwise a silent installation is possible using the following command line statement:

\\ServerName\IDEinstall\vs_Product.exe /adminfile AdminDeployment.xml /quiet /norestart

This statement is also the way of managing Visual Studio installations, both quiet and interactive. Again, everything relies on the AdminDeployment.xml file.

Visual SourceSafe to Team Foundation Server step by step

Fri, 03 Aug 2012 07:51:00 +0000

As I tweeted some weeks ago, the Visual SourceSafe 2005 support expired July 10th, 2012. So it is no more a supported solution from Microsoft.

If you have some Visual SourceSafe still lying around your datacentre, here’s how to kill them with no pain

First of all: you’re going to need the VSSConverter, a fantastic tool contained in the Visual Studio installation, under

<drive>:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE

Beware: with Team Foundation Server 2012 there’s going to be a new tool to perform migrations. I’m going to post something on the new tool as soon as I can, but for now this is the only way to migrate it. Moreover, if you won’t have Team Foundation Server 2012, you have not that much possibilities…

I strongly suggest you to copy the VSSConverter and its related files inside a folder, like <drive>:\Migration, in order to keep everything simple.

Then you have to create two XML files: one is for the Analysis, and the other for the Migration. I won’t go into details, everything you need about those files are into the MSDN but…I provide you two samples here’s one for the Analysis, and here’s the other for the Migration.

To analyze the Visual SourceSafe database, use the following command (from an elevated command prompt):

vssconverter.exe analyze analysissettings.xml

It analyzes the Visual SourceSafe database (or part of it), and provides us a report, to understand whether there are errors, and a UserMap.xml file. Inside of it we can find the Visual SourceSafe users to map to the correct Active Directory user in Team Foundation Server.

What does it happen if I don’t map a user (for various reasons)? Well…despite it’s strongly suggested to do so, the difference in behavior is the following:

With:
Changeset 4121 – Committed by DOMAIN\UserWhoDidIt – Comment

Without:
Changeset 4121 – Committed by DOMAIN\MigrationUser – Comment (Committed by UserWhoDidIt)

After finalizing the user mapping, we use the following command to migrate:

vssconverter.exe migrate migrationsettings.xml

And the migration takes place that’s it!

Team Build Nuggets: Automatic publishing of Web Applications with Team Build

Sat, 21 Jul 2012 09:27:00 +0000

As we’ve seen in the previous post, we can automate the creation of a deployment package to automate deployment of web applications.

What we’ve seen until now is just the beginning: in this post we’re going to cover the fully automated deployment workflow.

But before of that, we need a prerequisite: the Web Deployment Tool.

It’s downloadable from the Web PI Installer, and the only configuration needed is this (on the target server).

After that, do you remember the MSBuild Argument to pass inside the Build Definition? It was:

/p:DeployOnPublish=true

Instead right now we need a little more verbose one:

/p:DeployOnBuild=True /p:DeployTarget=MsDeployPublish /p:CreatePackageOnPublish=True /p:MSDeployPublishMethod=InProc /p:MSDeployServiceUrl=<server> /p:DeployIisAppPath="Default Web Site/<mypath>" /p:UserName=<domain>\user /p:Password=<password>

It creates a package which gets pushed to the server running the WDT, and automatically executed.

Team Build Nuggets: XCopy Deployment

Mon, 16 Jul 2012 14:01:00 +0000

What’s needed to perform an XCopy Deployment with Team Build?

Just that as a MSBuild Argument:

/p:DeployOnBuild=true /p:DeployTarget=PipelinePreDeployCopyAllFilesToOneFolder /p:_PackageTempRootDir=\\<server>\folder

Team Build Nuggets: Deployment Package

Thu, 12 Jul 2012 16:37:00 +0000

A great feature inside Team Build is the capability of creating deployment packages from the server in order to automatically deploy the application to the target server.

It’s really easy, you only have to create a Build Definition:

and adding the /p:DeployOnBuild=true switch to the MSBuild Arguments.

After building you’re going to find a <Project>_Package folder…

…which contains the package itself.

How to deploy it? Well…run the .deploy script or wait for another Team Build Nuggets post

Baseless Merge 101

Fri, 06 Jul 2012 10:45:00 +0000

A Baseless Merge is a not-that-known feature of the TFS’ Version Control System.

It’s a merge made with two branches of a root with no relationship between them. For instance, two parallel ‘release’ branches.

The suggested way of performing a merge with two branches like those lying around is to reverse integrate the first one into the root and then to remerge inside the other child. But this approach is not always feasible, so you can perform a baseless merge.

It’s a rather risky operation: the Visual Studio ALM Rangers strongly recommend to avoid it, because of the inner troubles inside it: no propagation for deletions, and no auto-solving of conflicts.

Up to Visual Studio ALM 2010, the baseless merge was there! But it was not integrated inside the IDE, and then the only option was to use tf.exe (tf merge /baseless …).

Nowadays we have this feature inside Visual Studio 2012, so no more command line playing.

For instance, in this scenario I’d want to merge Feature1 and Feature2…

…I can do it by calling the Merge Wizard.

It’s explicitly warning me I’m doing something risky: the baseless merge has no relationship with its siblings.

Moreover, if you try to drag and drop from the Hierarchy Viewer, you won’t be able to do a baseless merge. As of its nature, it must be done just purposefully and not ‘by error’.

How to instrument an application with PreEmptive Analytics for Team Foundation Server

Mon, 11 Jun 2012 17:11:00 +0000

As I previously posted, in this release we have a powerful instrumentation tool for our exceptions: PreEmptive Analytics.

Given the required server side configuration, here’s what’s needed on the client side:

Open up Dotfuscator:

Set a new executable to target:

Then select Analytics…

…and we start adding attributes:

One of the few things we need is an Application ID:

Then we add the SetupAttribute to instrument our methods:

Here we need to configure the Endpoint: as a default setting, the address to set is tfsserver:8000/Message/Endpoint.ashx

The Teardown attribute is needed to clean up after the execution;

The only missing stuff is the configuration itself:

We go creating a new subscription:

Copy-paste the IDs needed (Company and Application). The most important setting here is the Threshold: if we set it to 1, we’ll have an Incident work item for every time the exception raises.

That’s it people

Forward Compatibility Patch for Visual Studio 2008 to support TFS 2012 and Service is out!

Wed, 06 Jun 2012 18:43:00 +0000

For who is still using Visual Studio 2008 and wants to connect to Team Foundation Server 2012 or Team Foundation Service, the GDR patch has just been released!

Here’s the download.

Matteo

Configure PreEmptive Analytics for Team Foundation Server 11

Wed, 30 May 2012 20:25:00 +0000

As I previously talked about, PreEmptive included an instrumentation and analysis tool for Team Foundation Server.

After you install it, it’s needed a little bit of configuration. So you have to open the PreEmptive Analytics Aggregator Administration Console:

On the left side, click on the + sign to add a Team Foundation Server.

After that, the form is populated with the data from TFS. You need to deploy the PA items then:

This operation adds a Work Item Definition, a query, and two reports if reporting services are found:

After that, you might have to configure the Exception Sets caught by PA, but that’s not required.

Limits: the PA Community Edition includes just one Team Project Collection monitoring and two Team Project inside it. It can only record unhandled exceptions and there is a three exception rules limit.

Step by step configuration of the Team Foundation Server and Project Server Integration Feature Pack

Mon, 14 May 2012 05:37:00 +0000

This post is aimed at helping who has never configured the Team Foundation Server and Project Server integration

First of all: do not use NT AUTHORITY\Network Service as a service account.

After this sanity check, the prerequisites: a Team Foundation Server 2010 or above, a Project Server 2007 or 2010, and the Microsoft Team Foundation Server 2010 and Microsoft Project Server Integration Feature Pack (FP for us , it must be installed on the servers)

Then, the configuration. It’s a four steps procedure, from the Visual Studio command prompt.

First: I register the Project Web Access with the Team Foundation Server.

Second: I map the Project Web Access with the Project Collection I need.

Third: I load the field mapping.

Fourth: I map the Project Server’s Enterprise Project to the Team Foundation Server’s Team Project

That’s it

How to run local Web and Performance tests with Visual Studio 11

Sat, 05 May 2012 18:16:00 +0000

In Visual Studio 2010 to run Web Tests or Performance Tests you were editing locally, you had to run them from the Test menu, telling Visual Studio itself to pick up the local.testsettings file.

In Visual Studio 11 everything has been reshaped, and now it’s only needed to tick the Active Load and Web Test Settings flag, after right-clicking on the Test Settings file.

Team Foundation Server upgrade of April 27th: what changed?

Thu, 03 May 2012 08:06:00 +0000

April 27th Team Foundation Service got upgraded to a new version. As you know (and if not, I’m going to explain now ), Team Foundation Service doesn’t have a RTM – GDR – Service Pack maintenance cycle, but every update is rolled out with a cadence of circa a month/five weeks.

Then, there are some new UIs…

You can now reorder your backlog using the Alt+Up/Down combination.

The taskboard has been improved for touchscreens.

You can filter your areas and iterations, really useful for large projects.

They removed the identity screen in most all cases, letting you automatically sign in with Windows Live. Why that? They found out some bugs because it was just a view to live.com, so for instance in Visual Studio it didn’t properly work. They’re now working on fixing it (remember: they already support other providers apart from Windows Live ID, because they use Windows Azure ACS, but this capability is currently disabled).

There’s now the Windows Azure 1.6 on the Hosted Build machines.

That’s it

Standard Environment in Visual Studio ALM 11 using Workgroup machines

Wed, 02 May 2012 18:17:00 +0000

As I mentioned before, there’s the possibility of creating Standard Environments using Workgroup-joined machines and not just domain-joined machines.

All you need is to use Shadow Accounts (ie. “DOMAIN\account” and “account” on the local machine, or both “account”), better in the form .\account.

The magic is behind that is really easy: as the Microsoft’s KB says, “…NetLogon does not differentiate between a nonexistent domain, an untrusted domain, and an incorrectly typed domain name.”.

So if you use the same account&password couple, you won’t have problems in using them in Standard Environments

Creating Standard Environments in Visual Studio ALM 11

Sat, 28 Apr 2012 10:21:00 +0000

What’s new in Visual Studio Team Lab Management 11? Well, IMHO the most important new feature is the Standard Environments capability.

As far as today, if you wanted to use VSTLM you were forced to use Hyper-V and System Center Virtual Machine Manager to get the full flavoured Lab Management. Other kinds of machines could have been used, but it was not that automated and integrated.

Today with VSTLM 11 you can use whatever you want reaching almost the functionality of the Hyper-V and SCVMM equivalent! (with some exceptions we're going to see).

The only prerequisite is to have a Team Foundation Server 11 (Express, Basic, tfspreview.com, whatever…) with Team Build installed and configured.

We have to install the Test Controller…

…and we have to configure the Test Controller (default configuration at least, which is by setting the linked Project Collection):

That’s it! Obviously you won’t get the automated provisioning and all it’s related to SCVMM, but now you can use VMWare, Xen Server, physical machines or what you want with no hassle!

Let’s see how to create a Standard Environment:

I insert the machine name, the credentials for the test user (it must be a local administrator on the test machine) and what role does it ‘impersonate’ (it can be: client, server, web server, web client, domain controller, database server).

If I need them, I can use some tags:

Then I have to configure the capabilities for the tests I want to execute (unit tests, Coded UI tests, etc.)

Now it does some checks on prerequisites:

And then, it installs the needed agents and prepares the machine to be used. It takes some minutes, don’t worry

Finished!

Now I can use it for my Build-Deploy-Test cycle.

Limitations: I can use only Windows Server 2008, Windows Server 2008 R2 and Windows 7 as a guest OS. For now, there’s no support for Windows 8 and Windows Server 2012, it will be supported by far in RTM or RC (I still don’t know).

The machines must be in a Active Directory domain, because you need a trust relationship with the Test Controller in order to automatically install the agents. In a later post we’re going to see how to workaround this and use workgroup machines

Last but not least, here’s the MSDN documentation.

Run alternative unit test frameworks from Visual Studio 11

Mon, 16 Apr 2012 05:49:00 +0000

With Visual Studio 11 the whole set of testing features has been trashed out and remodelled upon a completely new shape.

If until Visual Studio 2010 you had as a default and mandatory choice MSTest (apart from the fact that you could patch-and-try another test framework, but that was not for mainstream developers IMHO, and moreover it was out of the IDE itself) from Visual Studio 11 on you can choose whatever testing framework you want.

The magic running underneath is quite simple. If before MSTest was just the way to do, now the whole test runner and all the testing tools rely on a brand new pluggable layer, which means you can plug-and-play (it sounds so Windows 95ish, isn’t it? ) NUnit, xUnit.NET, and all the frameworks that will provide a plugin to integrate in Visual Studio 11.

This is true on a test project, but even inside a test class!

To add support to other test framework is astonishingly easy: you just have to add them via NuGet:

Then you can remove the Microsoft.VisualStudio.TestTools.UnitTesting reference from your code, add the NUnit (or whatever) one, and start writing down tests as you always did with your favourite testing franework.

Excluding actions on certain software using Microsoft Test Manager

Tue, 10 Apr 2012 15:57:00 +0000

The possibility of doing Exploratory Testing (as I mentioned in my last post) includes some times where you have to use certain tools without being recorded by the MTM recorder.

You can configure selective exclusion in MTM just by selecting Local Test Run under Test Settings in Manual Runs on Test Plan’s properties:

Then opening it you’re going to find out, under the Data and Diagnostics tab, the Action Log flag.

Clicking Configure, you can specify certain applications for which you do not need recording actions:

Tips for Exploratory Testing in a real world consultancy scenario

Thu, 05 Apr 2012 18:50:00 +0000

As the name itself suggests, Exploratory Testing is made to explore.

One of the best scenarios you can use it is in the early phase of a consultancy.

Imagine it, you’ve being called to fix some bugs and improve a web application. A deep look at the code is mandatory but…why not to add a lap around the web application itself, in order to quickly understand where principal bottlenecks may be located.

So, to do that, open MTM, connect to the related Team Project on Team Foundation Server, and create a new Test Suite for your Exploratory Testing (XT from now on) run.

Then start the session:

While you’re testing your application, you can use other softwares (fiddler, for instance).

Once you’ve done with it, you can attach whatever form of log or file (via a Network Share or a URL) to the Test Plan to make it more explanative as well.

It enables new scenarios based on exploration, really useful for developers hired on a need.

How to get IntelliTrace in production for Windows Applications in Visual Studio 11

Wed, 28 Mar 2012 11:01:00 +0000

As we saw in the last post, we can get IntelliTrace logs from web applications.

But this is possible for Windows Applications, too!

Locate the IntelliTrace application under C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\CommonExtensions\Microsoft\IntelliTrace\11.0.0.

Then launch it, with the following syntax:

intellitrace.exe launch /cp:<CollectionPlanPath> /f:<LogFilePath> <ExecutablePath>

That’s all, we finished

After that the itrace file is analysable as usual.

How to get IntelliTrace in production for Web Applications with Visual Studio 11

Sat, 24 Mar 2012 08:53:00 +0000

Until yesterday, IntelliTrace in production environment was not supported, so the usefulness of it was a bit argued.

But now with Visual Studio 11, we can collect IntelliTrace logs from production environment in a completely supported way! And moreover, if you ask the Microsoft CSS (Customer Support Service) for help, the first question would be: “May you send me the IntelliTrace log please?”

Before of configuring IntelliTrace logs collection, we have to set security for the IIS Application pool account:

icacls sitepath “IIS APPPOOL\<AppPool Account>”:(F)

Then, hands on the bits. Suppose we have a web application throwing an exception.

Firstly, we have to deploy IntelliTrace to the target environment. Pretty easy, just extract content from the IntelliTraceCollection.cab file you can find under the C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\CommonExtensions\Microsoft\IntelliTrace\11.0.0 path.

Then we have to extract it to the target server. I suggest using the expand command from a command prompt:

expand.exe /f:* IntelliTraceCollection.cab path

Lastly, bring up PowerShell:

We have to load the IntelliTrace PowerShell Module:

Import-Module sitepath\Microsoft.VisualStudio.IntelliTrace.PowerShell.dll

After doing so, we can get the full list of commands we can use:

Get-Command *IntelliTrace*

And now we collect logs about the target application:

Start-IntelliTraceCollection ApplicationPool CollectionPath OutputPath

CollectionPath is the path we chose for IntelliTrace. In there, there are two “profiles”: collection_plan.ASP.NET.default.xml which collects only IntelliTrace events, and collection_plan.ASP.NET.trace.xml, which traces also function calls and events.

OutputPath is where we store logs.

After deciding Yes (to all ) we have to run the application.

When we got the error, we have to snapshot the log file:

Checkpoint-IntelliTraceCollection ApplicationPool

And then we have to stop collecting it.

Stop-IntelliTraceCollection ApplicationPool

That’s all: we have the logs.

To analyse them, it’s just a classic IntelliTrace analysis as we always did.

Code Review in Visual Studio ALM 11

Tue, 20 Mar 2012 14:39:00 +0000

Code Review is one of the new features in Visual Studio ALM 11 focused on collaboration among team members.

Everything starts with a request for review: you can add as much reviewers as you want.

Then after submitting the request, a work item is opened on behalf of me for the reviewer(s).

The reviewer can see there’s an incoming activity:

Opening it the Team Explorer shows up all the information needed.

Clicking on the code file affected by the review brings up the new diffmerge (we’ll see some insights about it in a later post).

I obviously can add a comment on my review…

…and define how did I valued the content:

After sending the completed review, the requestor has a complete overview of what did the reviewer do.

Mostly important: now Code Review is not an external process, but completely merged into the ALM in a seamless way.

Continuous Test Runner

Thu, 15 Mar 2012 20:28:00 +0000

Continuous Testing means running unit tests after each build in an automated way.

In the new Team Explorer, we have this functionality built-in.

To enable it, the only needed task is to check the Run Tests After Build flag under the Unit Test Settings menu:

That’s it, now everytime we hit CTRL+SHIFT+B our test suite is going to be run again.

What’s happened to Test Impact Analysis?

Mon, 12 Mar 2012 11:43:00 +0000

If you remember Visual Studio 2010 () there was a nice feature called Test Impact Analysis. It used to analyse your test suite and provide a report of what’s being touched.

In Visual Studio 11 this feature is no more available in the IDE, but it’s inside the Team Build, and enabled by default.

If you go through the Build Definition settings, and you look at the Process Template for the build, you can see the Test Impact Analysis is still there:

And it’s enabled by default

Licensing changes for Team Foundation Server

Fri, 09 Mar 2012 06:53:00 +0000

Mr. Brian Harry informs us that Team Explorer Everywhere, the cross-platform solution to access Team Foundation Server from Eclipse-based IDEs, running on Windows, Mac OSX, Linux, and different flavours of Unix is now free of charge!

So now it’s exactly as the Team Explorer. This change is for the 2010 SP1 version too.

Then: no more CAL required to access Team Foundation Server’s reports!

Latest: integrating System Center Operations Manager 2012 with Team Foundation Server, who does SCOM operations will no more need a CAL.

The Brian’s post is here.

Have a nice day

Code Clone Analysis: a quality enhancer in day by day use

Thu, 08 Mar 2012 10:49:00 +0000

A huge problem we have in team development is code recycling.

Sometimes it may be good, recycling some factory-like code we previously created to be reusable, but most of the times it’s a mere copy-paste which leads to problems.

In Visual Studio 11 we have a great aid in avoiding this: Code Clone Analysis.

By selecting a code snippet, we can right-click it and selecting “Find Matching Clones in Solution”

It searches in the current document for clones, with various level of matching

This could be extended to the whole solution, by selecting “Analyse Solution for Code Clones” under the Analyze menu.

My Work: changing the foundation of Team Explorer

Sun, 04 Mar 2012 15:19:00 +0000

In this release of Visual Studio one of the biggest change is the new Team Explorer, completely different from the previous release.

The first thing you are going to notice is the concept rounding around it: “what do I have to do?”

Starting from the foundation, one of the Visual Studio ALM 11 pillars is to allow seamless communication inside the development team. This is the base of the new Team Explorer.

So, here it is!

Everything is one click away, Web Access, Pending Changes, Work Items.

My Work is the latest addition, and the biggest and most noticeable.

Using it, we notice My Work evolving to a status dashboard answering the “what do I have to do? (and what did I do?)”

So at the moment of the check-in we now what did we modify, related to what, enabling a fluent and ‘easy’ user experience.

PreEmptive Analytics Community Edition

Fri, 02 Mar 2012 22:00:00 +0000

Before I start talking about Team Foundation Server 11, I want to point out a little new thing came out with the Beta wave.

TFS11 now includes a Community Edition of PreEmptive Analytics, a service which aggregates informations from applications’ crash and provides automated work items creation.

It’s installable from the Team Foundation Server Configuration Center

In this brief video Justin Marks, Program Manager for Team Foundation Server, shows up how it works.

Speaker @ MS Days 2012 in Sofia!

Thu, 01 Mar 2012 19:58:00 +0000

I’m going to have two sessions in this big conference, held in Sofia, Bulgaria.

The first one (on March 28th) is an introduction to Visual Studio ALM 11, the wonderful new platform from Microsoft for Application Lifecycle Management.

The second one (on March 29th) is a hands-on session on how Hyper-V can be a must-have aid for developers.

It’s one month to go, see you there!

Team Foundation Server Express Installation

Thu, 01 Mar 2012 06:27:00 +0000

With the Visual Studio ALM 11 release of yesterday, one of the greatest things you may notice is the presence of a Express Edition of Team Foundation Server 11.

It has some limitations, obviously:

Just Single Server installation
It relies on SQL Server 2012 (currently RC0) Express Edition
It has only Source Control, Work Items Tracking and Build Automation
Some agile management stuff like the taskboard, but no planning or feedback management tools
Free for five users
No Reporting Services
No SharePoint
No Version Control Proxy

Here’s the installation on Windows 8 Consumer Preview

Classic installation page, accept the EULA…

Do I really want to install it? yes I do!

Just a note: a new metro-fied icon it enforces the meaning of team collaboration IMHO

Meanwhile we’re talking about the new icon, the installer copies all the needed files…

Done Now configuration:

Next…

If we don’t want to configure a different port or user account for Team Foundation Server we may click Next…

Pre-installation readiness checks: everything runs fine

It configures all the needed stuff…

That’s all folks!

Then we have a brief recap of the installation.

With a bunch of clicks we have an essential but full featured ALM platform, totally free. Remember that with the new Visual Studio 11 Express Editions for Windows and Web you have the possibility of connecting to a Team Foundation Server.

We’re a long time away from the 2005 installations…

A new start

Wed, 29 Feb 2012 22:28:00 +0000

At the end…I did it.

I thought a lot of times about having an english-only blog…but I never had enough time to make a decision based on some requirements (I already started talking in ALMish slang…shame on me!) I had, like self-hosting, the blogging platform, etc.

Tonight I decided to open it So, here is the place. Why Blogspot? Wordpress didn’t have a free url with MattVSTS, my nickname that was the reason.

From now on you’ll essentially find posts I write in italian on my other blog, written in English. And the future direction of this blog is going to be decided by the direction my life is going to take. So…maybe surprises are around the corner!

Quite philosophical, isn’t it?

Anyway, some infos for the folk who came on this blog rounding about the Internet…

My name is Matteo, but just call me Matt, it’s easier.

I’m a Visual Studio ALM MVP since 2010 (well…I was a Visual Studio Team System MVP in 2010, before the name changed and as you can see from my nickname, I loved that name!), former Microsoft Student Partner (youngest ever in Italy, and the first ever being both MSP and MVP) and a 360 degrees geek.

I guess that’s enough for today

About

Welcome, this is my technical blog. I work in the technology industry, and my focus has always been on Application Lifecycle Management, DevOps and modern Software Engineering practices.

Here you won’t find much code on its own, but a rather different approach based on certain features of the tools I know and deal with on a daily basis. I am a solution-focused enthusiast, technology on its own just bores me. What really makes me tick is when a good crafted technology solution design meets a well executed business process, providing value at an order of magniture larger than the effort.

I hold a Professional Scrum Master 1 certification, but I am more of a pragmatist - processes should bring value, not just the inhevitable disruption followed by change. I believe we should always do what makes sense in an organisation.

Since 2010 Microsoft awarded me a Most Valuable Professional Award for my contributions to the community, an effort I do on my own time and which I really care about. I am also a founder of several technical communities in different countries, where I contribute by running the regular community meetings, organising conferences or facilitating networking, and a regular speaker at European meetups and conferences.

Speaking engagements

This is my speaking calendar for 2026

I am always happy to come and speak at your meetup, event or conference.
You can find my speaker profile here with my most recent abstracts, however feel free to get in touch if there is a specific topic you would like to see discussed.

These are my currently confirmed engagements for 2026!

February

DevOps Society - London, UK
DDD North 2026 - Hull, UK

March

Azure AI Connect 2026 - Online
DevOps Not Dead 2026 Q1 - London, UK

May

DevOpsCon London 2026 - London, UK

June

DevOpsCon Berlin 2026 - Berlin, Germany
VibeKode Munich 2026 - Munich, Germany