Companies face an increasing pressure to develop, test and deliver software faster, better and cheaper. These expectations make companies to actively seek ways to shorten the time to market/production.

You heard about Dev/Test environments in Azure, but you’re still not sure how it would work in your case? Or how can you simplify and speed up the process of running dev/test environments? By all means setting up development/QA/staging environments has never been easier. With Azure Resource Manager, once you set it up it is very simple to create identical environments in a repeatable way, as it is needed for multiple deployments throughout the development process.

If you’re new to Dev/Test with Azure or you’d like to easily understand the difference between the classical on-premises approach and Dev/Test in Microsoft’s cloud, you can check out this Dev/Test infographic. It gives you a quick glance at the key differences between the on-premises vs. the cloud approach of doing Dev/Test.

So we thought of helping you get a quick jump start with Dev/Test in Azure with the most relevant information on the big whys and hows of Dev/Test. We recorded a 4-episode video series. In total, they sum up to around 35 minutes, but at the end you will be able to better understand the role and importance of Dev/Test, as well as the benefits it brings to your team and company.

In this 8-minute video, we’ll go together through the major decisions an organization has to take when migrating an existing solution to Microsoft Azure.

Should we do it?

Which would be the best solutions to start with?

What should we expect from the solution once it runs in the Cloud?

Porting an existing solution from on-premises to Microsoft Azure comes with certain challenges. Most of these challenges are related though to choosing the right way to migrate and the models of cloud service that were took into consideration. Therefore, the better the research and planning, the easier the migration will be.

Migrating An Existing Solution to Azure

First of all, let’s discuss some limitations that you might encounter when you host solutions on premises.

Challenge #1: Scaling issues

How do you predict / estimate future users’ load? – It’s really hard to predict how many users the application will have next week or in 3 or 6 months’ time. Estimates are often wrong, so wrong that a lot of business can be lost. Hard to scale on demand – Ideally, your solution would be able to scale based on the user needs, based on metrics on its own. This is very hard to implement in an on-premises infrastructure. Takes days or weeks to do it – Saying you are able to scale manually, it takes days or even weeks to do it, because you have to go through the proper purchasing workflows and processes that you might have in place within your company. So on-premises, it’s close to impossible to autoscale in minutes.

How Azure can help? – Autoscaling

Autoscaling, or when the solution scales itself. There are lots of features which enable autoscaling. However, the autoscaling happens on demand only, based on some performance counters or metrics that we want to look at. It usually takes minutes (not hours or weeks) and depends on preset settings and constraints based on your budget constraints, the disaster recovery you need to consider etc. Takeaway: with consideration to those constraints, the solution is able to autoscale itself.

Challenge #2: Capex

Capital expenditure – you must an upfront investment when you want to host your solution on your premises. There’s the risk to render the solution as obsolete before you streamline your investment, especially when you consider that the equipment investment needs to be big enough to accommodate your highest load. This investment would sit unused for probably months or more than 50% of the time. Which shows that this approach isn’t efficient in terms of investment.

How Azure can help? – Pay per use

You get to pay only for what you use. You are able to shut down or scale down resources in a very efficient manner. Whenever you stop those resources, the costs go down as well. Many features like automatic shutdown, automatic stop can be found in Azure Automation, where one can define Powershell scripts based on which your solution will be able to scale up or down, paying just for what you use.

Challenge #3: Maintenance costs

You’ve got an ongoing cost that must cover services like disaster recovery and high availability are usually needed in your solutions, so you have to personnel taking care of the above-mentioned services. You spend man hours, and you enforce procedures in order to maintain them. Which leads to ongoing maintenance costs.

How Azure can help? – Lower ongoing costs

Disaster Recovery and High Availability are built-in, so don’t need to anything in order to achieve this. Virtual Machines in Azure are not just Virtual Machines – it’s not a 1:1 relationship with the VMs that you’ve got on premises. They come with a lot of extra features, for which, on premises, you would have to work to set up. When talking about Platform as a Service (PaaS), the maintenance work is near zero.

About the author

Mihai Tătăran is the General Manager of Avaelgo, and a Microsoft MVP on Microsoft Azure, Microsoft Azure Insider, and Microsoft Certified Professional. Mihai has been teaching Microsoft technologies courses to software companies in Romania and abroad, being invited by Microsoft Romania to deliver many such trainings for their customers.

Desired State Configuration (DSC) is a new management platform in Windows PowerShell that enables deploying and managing configuration data for software services and managing the environment in which these services run. During this video, we’ll see why Powershell DSC is a great feature that helps us a lot Dev/Testing with Microsoft Azure.

When trying to setup an environment, things like:

a local account

a special service

a process

a configuration in IIS

etc.

take time and may be the source of many mistakes.

With PowerShell Desired State Configuration (DSC), creating dev / test / staging environments has never been easier. You can now specify how the VMs should “look like”, and establish their desired state (state that the VMs will be able to reach automatically).

“PowerShell DSC is a great mechanism to specify prerequisites on VMs, and also to make sure VMs are created in an identical manner, every time we need to deploy into the same type of environment.”

This is the forth video in the Dev/Test series. We recommend you also watch the previous videos:

In the previous videos we’ve seen how we can create environments for Dev, QA or Staging purposes in Azure. Most of the time, in order to deploy a solution in such environments, we need specific prerequisites to be installed on the Virtual Machines.

Why use PowerShell DSC in Dev/Test scenarios with Azure

A continuous integration process may look like this —

You have your source code (say in Visual Studio), source code that is maybe checked into TFS or VSO. And you want to deploy a new version into a specific environment (dev/test/staging etc.). The steps you need to follow are the classical continuous integration steps from VSTS: build, release and so on.

After the environment has been created in Azure, which is actually an Azure resource group, you have to deploy your solution on that environment.

Let’s zoom in a bit to see how Powershell DSC can help us a lot in these scenarios.

When you deploy your solution, you already have created and configured the Virtual Machines, load balancers, storage accounts – whatever the solution needs. All these should already be created as components in Microsoft Azure. The actual solution deployment (before you actually deploy the bits and the resources that compose your solution), you need to install and configure some pre-requisites on the VMs which are running the solutions. Such as a Web server, a local account, a Windows service, load other components and other required configurations.

Those prerequisites can become a challenge sometimes. Because you have to make sure that those prerequisites must be installed every time identically you make a new deployment in test / staging / production environments. This is the challenge: how do you make sure all those prerequisites are reused every time, in between environments or in between versions of the solution into the same environment.

I would say, a particular case, would be to make sure when you move from staging to production, when you have concluded that – Yes, this version has been tested and can be moved to Production – why not here be able to reuse the same pre-requisites.

Powershell DSC is a set of technologies which have been designed exactly for that. You are able to specify how the VM should look like, the desired state of those VMs. There are 2 mechanisms to make sure the VMs have the desired state: VM PUSH – you simply push the specification (the DSC) on to the VM and all the differences will be applied; VM PULL – the VM will check its’ state against a desired state specified somewhere from time to time and will be able to refresh its state.

The most important thing here is that using Powershell DSC you’re able to specify how it should look like. It’s not a procedural language where you say – install this, configure that and so on and so forth – it’s a state that you define which makes us be certain of the fact that this state will be exactly how it’s described (we’re not going to miss anything, we’re not going to install something by mistake etc). Having the DSC we will be able to use the DSC configuration throughout deployments or different mediums.

If you want the dev environment to be identical with the test environment, you simply reuse the same DSC. If you want the staging environment to be identical with the production environment, again, you reuse that specific DSC. By the way, this is a big challenge – whenever you want to promote your solution to production, which let’s say, it’s on a client’s environment, it’s always a very hard thing to do. Because you don’t have access to your customer’s infrastructure all the time, probably you’re not allowed to play with it, and what we end up doing as software developers or software companies before actually launching into production a new version of the solution, we try to replicate the production environment into a staging environment in our own infrastructure / own Azure account for example. And trying to replicate an existing production environment is not always the best case, because you might miss something. There are a lot of configurations. So testing in a replicated environment will not be perfect, because of the differences of the two environments.

With the help of Powershell DSC you’re able to easily switch tables: you’re able to actually say this is how the environment should look like, this is my staging environment where we tested the solution and, dear customer, together with the solution that we’re providing you here is a set of DSC files which will bring your environment into the desired state. Thus allowing the customer to be able to create a production environment which is supported, which has been tested on and so on.

This is how it looks like. This is part of a DSC file, specifying things like I want this Windows feature to be installed. Once you compile this file will be able to further used (with an existing or a when you create a new VM).

Build your cloud strategy

About the author

Mihai Tătăran is the General Manager of Avaelgo, and a Microsoft MVP on Microsoft Azure, Microsoft Azure Insider, and Microsoft Certified Professional. Mihai has been teaching Microsoft technologies courses to software companies in Romania and abroad, being invited by Microsoft Romania to deliver many such trainings for their customers.

In this video, we talk about Azure Resource Manager and its role in Dev/Test scenarios.

One of the biggest challenges development teams face is to be able to create Dev or Staging or QA environments, over and over again, in an identical manner. They usually spend a lot of time doing this, but with ARM everything becomes much easier, because of the JSON template we are able to specify, and based on which Resource Groups will be created.

“Azure Resource Manager (ARM) is a fundamental technology which is going to be used more and more in a variety of places across the Azure platform, and its main advantage in Dev/Test is the ability to create environments, no matter how complex they are, in a repeated way.”

Before starting, check out the first videos in the series for a short introduction.

In a nutshell, we see two major advantages in using Dev/Test with Microsoft Azure:

Optimizing the development process – you have a more optimized development process

Cost efficiency – you’ll be more efficient in terms of costs.

First, developers won’t have to wait for the infrastructure team to create the development / test / staging environments. They will be able to create them themselves, in a self-service manner.

Secondly, most of the environments aren’t needed all the time, 24/7 year round – they are needed only hours per day, or a few days per week etc. There are mechanisms which allow us to minimize the costs.

Dev/Test with Azure Resource Manager

Going into further details, we’ll try to explain how Azure can help when dealing with more complex solutions. The following image shows how a (short) continuous integration process looks like.

Say you’ve got the source code in VSTS from which you proceed in the next 2 phases: the Build and the Release phase (both explained in the intro video of the series). After you have build your solution and start deploying, first of all you need to create the environment in Azure.

Imagine you’re in the process of developing a solution and you’re using Dev/Test in Azure. At the end of every iteration you need to deploy the solution you’re working on intro a staging environment, for testing purposes. And that staging environment needs to be created before the actual deployment of the solution. Once you have it up and running, you then may proceed and do the solution deployment with all VMs prerequisites.

Next, we’re going to focus on environment creation. Creating an Azure environment is created from Visual Studio Team Services (VSTS). The smart thing about Azure is of being able to create complex environments (load balancers, virtual networks, storage accounts, IPs, VMs, etc).

No matter the complexity you will be able to create the environment, in an automated fashion, repeatedly and identically.

There’s a concept called Azure Resource Groups (Azure Resource Manager). They are nothing else but containers of resources that should and must belong together. Resources should belong together from many perspectives, but the most important one is the development life-cycle.

For example, if some particular resources (a database and a website) are created together, and later, should be stopped / deleted together, they definitely belong into a resource group. Usually, you deploy a solution in an environment which is actually a resource group.

The smart thing about resource groups is that they are based on JSON templates. JSON is a manner to describe how those environments should look like. This mechanism actually allows us to avoid the big complexity around creating big environments with many components.

Build your cloud strategy

About the author

Mihai Tătăran is the General Manager of Avaelgo, and a Microsoft MVP on Microsoft Azure, Microsoft Azure Insider, and Microsoft Certified Professional. Mihai has been teaching Microsoft technologies courses to software companies in Romania and abroad, being invited by Microsoft Romania to deliver many such trainings for their customers.

Many of our clients ask how Visual Studio Team Services (the SaaS equivalent of Team Foundation Server) integrates with Azure in order to deploy solutions into the Microsoft Cloud.

If you’re new to Azure and Dev/Test with Azure, you probably need an introduction on why it’s worth developing and testing with Microsoft Azure. Make sure you check out the first video of this series – we covered the core benefits of Dev/Test with Azure. And we also talked about how Microsoft Azure responds to the most common challenges companies face in their day by day activities:

the need of optimizing the development process using Azure through things like allowing the development team creating their own environments and not depending on an infrastructure team to create those environments.

a cost-efficient self-service at your finger tips – you can make sure that the Dev/Test environments are created and/or are live for the exact time-frame they are needed.

“The purpose of using VSTS and Azure is to stop using local / on premises infrastructure in order to build and release the solution.”

Next, in the second video of the Dev/Test series we’re showing how Visual Studio Team Services (the SaaS equivalent of Team Foundation Services) integrates with Azure in order to provision environments and to deploy solutions into the Microsoft Cloud.

Build your cloud strategy

About the author

Mihai Tătăran is the General Manager of Avaelgo, and a Microsoft MVP on Microsoft Azure, Microsoft Azure Insider, and Microsoft Certified Professional. Mihai has been teaching Microsoft technologies courses to software companies in Romania and abroad, being invited by Microsoft Romania to deliver many such trainings for their customers.

Today, almost all software development companies face a number of challenges when it comes to ensuring coherent environments and infrastructures for test, demo, staging, pre-production scenarios and so on.

With modern development, more than ever both applications and environments require frequent changes. However, setting up or modifying dev and test environments often requires a significant effort and long delays.

With the advent of cloud services, we’re presented with new possibilities for creating temporary environments, particularly because some key attributes of the Cloud.

In this video you will see how Microsoft Azure responds to the most common challenges companies face (for instance the need of temporary infrastructures, available on demand, for Development / Test / Staging environments).

“The main objectives of a Dev/Test strategy with Azure are enhancing the software development process and minimizing costs.”

What is actually Dev/Test?

Dev/Test is everything related to development and testing, continuous integration and continuous deployment, as well as what you need in order to setup staging environments, testing environments for the application or solution you’re developing. It’s usually part of the DevOps set of tasks a software company needs to perform.

Let’s see the Dev/Test challenges today – without the Cloud, using our own local infrastructure. The biggest challenge today any software company experiences is the major disconnection between development and infrastructure teams. This disconnection leads to a long, complicated, and inefficient development process. It also raises the question of who is in charge of the temporary infrastructure (the infrastructures that are needed for testing/staging that have a temporary nature).

Over the time, we identified some common situations software companies are facing. For instance: the development team asks for a staging environment (with a specific setup of a couple of virtual machines), for a proper functional and integration testing. This is usually done by sending a ticket to the infrastructure team. The relevant person in charge sets up the needed environments and then notifies the development team of the availability of the staging environment. However, sometimes the VMs are not configured exactly how the development team requested, so the process is delayed by submitting another ticket to the infrastructure team. In the end, the environment is configured and testing can begin. Once the testing is over, the development team sometimes forgets to notify the infrastructure team to remove the staging environment, which leads to cost issues.

And we’ve seen approx. 15-20% of the staging VM are not being used. Besides, being stating/testing environments, you need them on a really narrow schedule (only between working hours, not during nights etc.). This can lower the costs up to 40% in some cases. Just by stopping the VMs when you don’t need them and turn them on when testing is being done.

Lack of skills – the development teams don’t have the infrastructure skills they need to create a staging/testing environment. On the other hand, the infrastructure teams don’t understand all the time the requirements coming their way.

Why and how Microsoft Azure can help?

It’s self-service

Azure has been designed from the beginning to be a self-service set of features. A developer or anybody with no IT skills whatsoever can create very complex environments in Azure, as long as a template has been designed for them.

It’s elastic

Azure provides you a lot of features to be able to scale up or down, depending on the needs, and it all happens in a matter of minutes.

It’s fast

Provisioning of VMs takes only minutes to complete. It’s much faster than on-premises provisioning. For instance, it takes less than 10 minutes to create a VM, and also less than 10 minutes to create 100 VMs – and this is all because of Azure’s scaling up feature.

It’s cost effective

Cost control get even better and waste can be minimized by using quotas, access policies, automatic shutdowns. These budget savings end up being very important to the infrastructure teams.

It’s reusable

Azure Resource Manager (ARM) is one of the great things about Azure – it allows you to create an environment and then to use it as a template. You can export it as a template (JSON format) being easily further used by development teams to create new identical environments, based on the same template.

It integrates with existing tool-chain

Continuous Integration Tools

If we’re talking about Dev/Test, we can’t skip continuous integration tools from Microsoft because they integrate extremely well with Azure. These tools could be either Team Foundation Server (TFS) or Visual Studio Team System (VSTS) – the online version of TFS.

A very simplified process of Dev/Test in Azure

Let’s say you are using Azure to deploy your solution into the Cloud. This means that you have previously created there the needed environments, and that’s where you deploy your solution. This also means that you are able to use the resources from Azure to actually perform the build and perform the release.

You can forget about the concept of “build server”, which you may still have in your organisation. You don’t need that anymore. In Azure, you literally don’t need any kind of infrastructure (besides work-stations for your developers) to build, test, and deploy your solution.

This is the end of episode #1 of the Dev/Test in Microsoft Azure series. Now you know a little more on how you can enhance your software development processes and optimize your business with Azure.

About the author

Mihai Tătăran is the General Manager of Avaelgo, and a Microsoft MVP on Microsoft Azure, Microsoft Azure Insider, and Microsoft Certified Professional. Mihai has been teaching Microsoft technologies courses to software companies in Romania and abroad, being invited by Microsoft Romania to deliver many such trainings for their customers.