DevOps on the Microsoft Stack – Pre-order now

The last couple of months I’ve been bussy working on my new book: DevOps on the Microsoft Stack

DevOps on the Microsoft Stack Book Cover 3D

DevOps is a popular subject and Microsoft has a very good tool suite in the form of Visual Studio, Visual Studio Team Services, Team Foundation Server and Microsoft Azure. This books takes you on a tour through these tools.

You’ll learn about a host of features like:

  • Agile Project Management
  • Version Control with TFVC and Git
  • Technical Debt Managament
  • Package Management
  • Continuous Integration and Continuous Delivery
  • Testing and test automation
  • Monitoring

Pre-order now

Writing is almost finished and you can pre-order the book on Amazon or directly from Apress. If you order a copy, please let me know what you’re looking forward to! You can reach me through the comments on this blog or by sending me a tweet (@wouterdekort).

Have you seen the new dev/test labs on Azure?

One of the great scenarios for Azure is dev/test. Having the ability to quickly setup an environment in Azure and run your automatic or manual tests on them gives you an extreme flexibility. You pay per minute and you can have as many machines as you want in a couple of minutes.

But there are some challenges.

One thing I notice while working with customers is that they often want to limit how much money can be spent on Azure. Often customers asks for a cost calculation so they know beforehand how much Azure is going to cost them. Of course the whole idea of Azure is that you pay for what you use so giving of an exact amount is hard.

Another thing that teams sometimes struggle with is the amount of choice on Azure. You have different sizes of virtual machines, ranging from simple A-series to Godzilla machines. And add to that the number of virtyual machine images you can use, network settings and security configurations and a team can suddenly be overwhelmed with all the options they have.

Dev/Tests labs to the rescue!

During Build this week Claude Remillard announced a new Azure service: Dev/Test labs. You can now create one or multiple labs in your subscriptions. These labs can have a quota on how much can be spent. This means that a team can never go over the amount you configure, giving managers and others a nice and secure feeling.

But that’s not all. You can also configure which virtual machine sizes can be used, which templates are accessible and you can easily create custom base images for your team. The developer division at Microsoft uses this themselves. They have base images that contain stuff like the correct Windows version, Office and other standard tooling. Then each night they run a scheduled build that takes a base image, adds the newest version of Visual Studio to it and create a new image ready to go the next day. You can configure your lab to automatically shut down VMs at the end of the day to save on costs.

Now integrate this with the new Release Management service (a topic for another blog!) and you have a great new tool to automatically setup and break down environments on Azure.

Want to know more?

On Channel 9 you can find the recording of the session with demos showing the new lab features: http://channel9.msdn.com/Events/Build/2015/3-721. Currently this feature is in private preview but you can request to join: http://azure.microsoft.com/en-us/campaigns/devtest-lab/

I’ve requested to join the private preview. As soon as I’m up and running I’ll post more details on this promising new feature.

What do you think? Is this useful? Anything you like to see? Please leave a comment!

What I learned at the Microsoft ALM Summit

Last week I had the privilege of visiting Barcelona. A beautiful city with some great places to visit, nice weather and really nice food. But that wasn’t the goal of my visit.
Microsoft organized the West European ALM Summit in Barcelona last week. The ALM Summit is a partner event where all ALM partners have a change to get the latest ALM news and meet there fellow colleagues.

So from breakfast with Sam Guckenheimer to drinks with Craig Kitterman, the ALM summit is a great place to meet people and learn directly from Microsoft.

Cloud

The summit took two days. One day was focused on Cloud, the other day on Mobile. Which isn’t strange since Microsoft is a ‘Mobile first, Cloud first’ company.

Microsoft is really targeting the Cloud with its ALM innovations. From the new Cloud Deployment Projects to Dev/Test, ALM and Cloud go hand in hand as far as Microsoft is concerned.
Although I understand their goals, this sometimes means that new features have no value to customers who are solely on-premises. Of course Microsoft hopes that ALM Partners help customers move to Azure.

This is why Microsoft is pushing on using Azure for Dev/Test scenarios. And to be clear, Dev/Test on Azure is a great scenario. It’s cheap and flexible and with the Virtual Network support Azure offers, it’s also secure.

One particular area that was discussed are the MSDN benefits for Azure. Did you know that as a developer with an MSDN subscription you have free monthly credits for Azure? Depending on if you have a Professional, Premium or Ultimate subscription you get between $50 and $150 Azure credits a month that you can use to experiment with Azure and run small workloads.

In addition to Dev/Test scenarios, Visual Studio Online is also complimentary to your on-premises TFS environment. For example, Application Insights and Cloud Load Testing are features that you can use without storing any code in VSO but that really complement your on-premises TFS.

Mobile

The second day was all about Mobile. What I found particularly interesting was the comparison between Cordova and Xamarin. For example, Microsoft said they used Cordova for the Connect() event app. This app is only used for one or two days and is mostly about displaying data. Cordova is a great solution for apps that don’t require a great performance or deep interaction with the device.

Especially with the new Cordova support for Visual Studio, Cordova is something you should
consider for ‘quick and dirty’ apps. Xamarin is on a whole other level. This is if you want to invest in a quality app that runs natively on a device.

DevOps

What is totally clear is that MIcrosoft is focusing on DevOps with their ALM platform. This means that Microsoft invests in tooling that makes DevOps practices easier.

If you understand this focus it’s easier to understand why tooling like Smart Unit Tests is being released instead of investments in Coded UI.

Forrester gave a presentation where they showed that DevOps is required for succeeding in developing modern applications. For example, the most popular apps in the different app stores are all updated on a daily to weekly basis. This can’t be done without a good DevOps implementation.

So Microsofts vision is clear. They are really pushing on Mobile and Cloud and are underpinning this with their ALM tooling. Visual Studio 2015, Visual Studio Online and Azure will be the future of their investments and if we want to stay up to date as ALM consultants that’s where we should focus.

All in all, it where a nice couple of days and I’m looking forward to the summit next year! Are you looking into Cloud, Mobile and DevOps on the Microsoft stack? Please let me know!

My favorite books: Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation

Lately I often get the question: “Which books do you suggest?”. So since I have only have a finite number of key strokes left, I’m starting a list of books on my blog that I recommend.

The focus of the books I read are on ALM/DevOps and Microsoft technology in general. For me, reading is one of the best ways to learn. I use Twitter and blogs to stay up to date with new developments but if I really want to learn something, I love a good book.

So without further ado, here is a book I definitely recommend:

Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation

The fact that this book is in the Martin Fowler series should be a trigger for reading it. The Fowler series has some great books and this is no exception.

The book is all about moving a project to adopt Continuous Delivery. Focusing on the concept of a delivery pipeline it discusses the different phases in your pipeline and shows ways how to implement them.

The book does not specifically focus on Microsoft technology but the concepts discussed are technology agnostic so you can apply in whatever environment you’re working.

The book is not perfect. Some content is repeated quite often and I found the later chapters a little less interesting. However, if you are serious about ALM and DevOps, go get it now!

Did you read this book? Did you like it? Or do you have any other books that you recommend? Please leave a comment!

Have you already heard about PowerShell Desired State Configuration?

What?! PowerShell, isn’t that for IT pro’s? I thought this was a blog by a developer. Well, it’s true that I am a software developer at heart. But that doesn’t mean you should ignore what’s going on in the IT pro world.

Why should I care: meet Bob and Joe

Meet Bob the Developer. Bob works on a great new application: project Unicorn. He uses cool techniques like Angular, ASP.NET MVC, WebAPI and Entity Framework to build a stunning SPA. But in essence his application is a web based app with a SQL Server database.

Bob has a great team of developers and they are producing quite some code. After a couple of weeks, a tester joins the team and asks if there is a testing environment available. So Bob goes of to the IT guys and asks them for a new machine. Fortunate as Bob is, it only takes a couple of days before his machine is ready! He gets the credentials to remotely access his Windows Server. Now as a true developer, Bob knows how to install IIS and SQL Server by clicking next –> next –> finish. After doing this, he copies his website and database to the machine, fiddles with some configuration settings and he’s good to go.

All of this is done through a set of GUIs like the Control Panel and Microsoft Management Console. Now that’s not a big problem for Bob. He knows how to do this. And while doing this, he installs his favorite tools and plugins for Windows. Who likes that new start menu on Windows Server? And having Visual Studio locally on the test environment is much easier to debug some stuff.
Meet Joe, the IT pro. Joe is given the job to prepare a production environment for  Unicorn. He looks at Bobs test environment, shudders and starts working on a production environment with all the bells and whistles that are required to get a stable and secure environment that’s up to his standards.
Joe uses PowerShell. He needs to configure a lot of machines and he doesn’t want to do it by hand. Instead he has collected a great amount of scripts over time that he stores on his hard drive and shares with some of his colleagues.

Things start breaking down

Until now, this doesn’t sound to bad. Maybe you have been a Bob or a Joe in a situation like this. But then, Joe calls Bob.

Joe: Your application doesn’t work
Bob: Yes it does. It not only works on my machine but also on the test environment
Joe: But it doesn’t work in production and that’s the only thing that matters

Bob who clicked through all his GUIs has no idea what changes he made. And so the search begins. After a long and heated search, Bob and Joe decide they really don’t like each other. Eventually the problem is found: a permission setting is required for a logs folder.

So what does this have to do with PowerShell Desired State Configuration?

Can you explain what the following scripts does?

Configuration ContosoWebsite
{
param ($MachineName)

Node $MachineName
{
#Install the IIS Role
WindowsFeature IIS
{
Ensure = “Present”
Name = “Web-Server”
}

#Install ASP.NET 4.5
WindowsFeature ASP
{
Ensure = “Present”
Name = “Web-Asp-Net45”
}
}
}

It’s not too hard is it? This is a PowerShell DSC script. It instructs a server to make sure that IIS and ASP.NET are installed.

This script is plain text. It can be read by a developer and an IT pro. Now imagine that Bob would have set down with Joe when he started preparing a test environment. Instead of clicking through a GUI, Bob asked Joe to help him create a DSC script. This script describes exactly what state the server should be in.

Since it’s just a script, it can be added to version control. Now that it is in version control, it can be added to the package that Continuous Integration build creates.

Release Management Update 3 has support for DSC. This means that after your build finishes, Release Management takes your DSC files and applies them to the set of servers you have in your environment. At the start, these machines can be completely clean. Everything is configured automatically when the DSC script gets applied. Whenever someone makes a manual change to a machine, the script reruns and the machine autocorrects itself.

Now that the script is finished, can you imagine how Joe setups the new production environment?

If you want to know more about PowerShell DSC, have a look at http://powershell.org. They have some great resources on DSC.

Feedback? Questions? Please leave a comment

To version control, or to source control: that’s the question

One of the hardest things in software development is naming things. When designing your architecture, creating a method or adding a new variable: naming it correctly is half the work. This is why design patterns that create a shared vocabulary is so important.

But naming doesn’t only apply to our code and designs. We use all kinds of tools,. techniques and practices that need to have a name and some are around for quite  a while.

However, that doesn’t mean there isn’t any confusion on naming those things.

Version control or source control?

One particular area of naming problems is around source or version control. If you think about it for a moment, what term are the people around you using? What do you use? And can you describe the differences between those two terms?

For example, I was privileged to hear the following discussion at a customer:

Developer: we would like a way to bring the environment configuration under source control so we can version and test them
Ops: You don’t have to test our environment configuration. That’s our job. Our configuration scripts are not code so we don’t want to store them in source control.

Is it true that your source control can only be used for actual source code? Is that the reason we started using source control? Or do you use it for all your artifacts like documentation and configuration, build and deployment scripts?

When moving to a DevOps culture discussions like these are not uncommon. Making sure that you have a shared vocabulary with all stakeholders really helps in getting your communication running smoothly.

Switching from source control to version control is a small and simple step in that direction.