For the past 2 years I have been on a crusade of giving back to the community. For so many years I’ve consumed blogs, watched webinars and attended SQL Saturdays to learn things. I’m now at that stage in my career I want to give back.

Not because I’m the best in the field – that was what was holding me back – because I felt I had nothing to offer. I was so wrong.

I realised that I had the potential to talk about a topic that I’ve researched for weeks, months and years and that in the audience might be one person who didn’t know what I now know.

So in 2016 I submitted for every SQL Saturday in Australasia that I was available for and was lucky enough to speak at the PASS Summit in October 2016 – “Overcoming a Culture of FearOps by Adopting DevOps“.

Whilst speaking on tempDB at SQL Saturday Brisbane I met someone who was totally committed to community education – Nagaraj Venkatesan (t / b) and over the past 6 months we talk regularly via social media.

Nagaraj has setup a channel on YouTube and I was very honoured when he asked me if I would be one of his first interviews on it. The video below is 30 minutes long and after watching it a few times I realise that when I’m excited about a topic – you can definitely tell I’m excited about a topic….

Video at SQL Server Central

Yip.

 

 

Introduction:

This blog post is the first of many that I’ve had stored up in my brain and in saved drafts.

It was whilst I was preparing for my upcoming presentation at Ignite Australia about my experiences in getting DevOPs working at Jade Software that I realised I had a good series of stories to tell that could help others.

My session is called “Making DevOps work in the wild..” and is a collection of things I’ve had to do over the past 5 years to get stuff going. It describes how Azure and cloud services have enabled efficient, reliable and automated application deployments using DevOPs.

One of the principles of DevOPs is the integration of Continuous Integration (CI) with Continuous Delivery (CD).

Simply put CI is about merging all working copies of developer code into a shared repository several times a day. This is then built and tested using CI software to produce brilliant software – in the form of a package.

CD is about taking that product and ensuring that we can reliably release it at any time. We want to build, test and release our product faster, safer and more frequently.

For years I have administrated on-premises installations of both CI & CD tools. These typically run on virtual servers which were hosted on-premises.

With virutalisation of infrastructure it meant that operational people like myself could script the build of underlying server infrastructure and start to go down the path of Infrastructure as Code (IaC).

What is Infrastructure as Code?

This is the method of improving the way we manage and create the different servers/databases/apps etc (what I call environments) which occur along our CD deployment pipeline.

It allows us to script in a declarative, reusable, automated manner that creates the state of our environment.

The key thing about IaC is that because everything is in a script then it means we can version it in a source control repository.   Version Control has been a key component of CI processes for DEV for years – what this means is that us OPs guys can utilise this our scripts and if required we can restore a known version of an environment at any time.

It also means that DEV and OPs now have something we can discuss and collaborate on. If DEV need certain features for a particular environment (say our Functional Test (FT) environment) then this can be implemented very quickly and at the touch of a button. If successful then we can roll those changes out to UAT, prePROD, Staging and eventually PROD.

How can Azure help us?

With the advent of cloud services such as Azure – which is Microsoft’s cloud computing platform – we have access to a collection of integrated services such as computing, database, mobile, networking, storage and web which will allow us to build on Infrastructure as Code and deploy applications much faster and importantly – save money.

The best part is that you can try out Azure using a free trial:

Which is awesome – I signed up for the free account when I first wanted to prototype things on Azure.

Going back to CI & CD – as mentioned I administrated a lot of these on-premises. Which meant that my team and others were involved in installing/configuring and continuously patching the servers and running software. Which meant that even though we had IaC nailed, we still had to be involved in the day to day running of the infrastructure that hosted out CI/CD software.

Enter Azure…

The great thing about Azure is the MarketPlace:

The marketplace is growing almost daily and is the online store for thousands of certified, open source, and community software applications, developer services, and data—pre-configured for Microsoft Azure.

What this means is that if I want to run up an online version of one of my favourite pieces of deployment software:

Octopus Deploy

Then I can browse the Marketplace and have this going very quickly. In fact if you are looking at how to do Continuous anything in Azure you should visit this blog:

http://dinventive.com/blog/

For myself I used this post for running up my Octopus Deploy in Azure.

http://dinventive.com/blog/2016/10/11/5-clicks-and-under-15-minutes-octopus-deploy-running-in-microsoft-azure-ci-tools-as-code/

The blog is slightly wrong as it only took 8 minutes to have a functioning installation of Octopus Deploy.

This means that my installation is running and all I have to do is consume it in Azure. The patching of underlying SQL Server and Windows Server are taken care of.

My time can now be spent on better things than ensuring my infrastructure is fully patched.

A special mention is that by using the templates in Azure also means I can punch out applications and services as I need to. This is why I consider using Azure to be “Infrastructure as Code+”.

Tools to manage Azure:

The full Microsoft development stack makes this very easy – you can use:

Visual Studio with Azure SDK

Management portals:

https://portal.azure.com

https://manage.windowsazure.com (old portal)

Azure PowerShell

Azure CLI

 

I’ve used all 4 methods to familiarise myself with how to spin things up in Azure and I will go into each as I write about various aspects of creating Azure resources.

For now here is a teaser for creating an App Service.

Using Visual Studio:

We would create a new ASP.NET Web Application and ensure that we’ve chosen “Host in the cloud”:

More detail and a tutorial can be found at:

https://docs.microsoft.com/en-us/azure/app-service-web/web-sites-dotnet-get-started

Using the Management Portal:

Sign in with your account and choose New and browse to “Web + Mobile” and choose “Web App”:

The great thing is that Azure Resource Manager will fill in as many of the entries as possible to make our life easier and slightly more consistent.

Using PowerShell:

Because this is my preferred method of creating anything in Azure (along with templates) I will write a post dedicated to this.

Conclusion:

Managing Azure is fairly easy and intuitive – you do need to stay focused though – it is a behemoth and it is easy to get lost or consume a lot of time trying out some of the brilliant features in it…

Hence why I signed up for the free trial – I had some goals in mind but it was awesome just spinning things up to see how they could be utilised.

Recently I’ve had to use Azure to solve a database deployment issue for myself and the company I work for. It was extremely easy to spin up the resources I needed – thanks again to Infrastructure as Code, Azure templates and Visual Studio Team Services (VSTS).

I am looking forward to writing about my experiences running/administrating Team Foundation Server in-house versus the ease of VSTS in Azure.

Today’s post is the first of many which will describe my journey in Azure and also how it can help you achieve deployment greatness utilising repeatability and predictability which are keys to any successful deployment of a high-scale application or database.

 

Yip.