I’m a technical guy.

Thus – I love tools. They make stuff go.

Tools are great.

Except – as I wrote in my other post — DevOPs and Databases — the one thing you may be doing wrong.  You can’t just focus on one thing in DevOPs.

You need to consider Tools, Process, People and Culture.

Today I took a trip in a time machine. I visited Past-Hamish – the bloke I once was in 2012. A guy who didn’t do powershell at all, and his source control was some versioned files in folders…

Ugh.

He was however a guy who had a problem – manual error-ridden deploys of .NET systems and so he wrote some scripts. He even started talking to Developers.

Nice.

His tool of choice at that time was good old notepad and some of this stuff:

At the time Continuous Integration was kicking off  in Past-Hamish‘s workplace and so the result was a standardised artifact package from the build server.

So with the above script – which was an awesome 690 lines of ‘code’ – –  Past-Hamish managed to get some repeatable deploys going on.

Yip.

They eventually morphed into repeatable, reliable and automated deploys and by 2014 they were truly an awesome thing to behold. They even started to fit into the Continuous Delivery processes we were doing. By that stage we were using PowerShell and Octopus Deploy to really achieve deployment brilliance.

it is kinda obvious in my posts that I really like Octopus Deploy – it is a great tool and it allows us to refine our deployment process. And it is very, very affordable.

So why didn’t we port this particular application thing over to it? A lot of factors – none related to actual tool stuff. Here’s the thing – that script Past-Hamish wrote (in collaboration with DEV) works. It works really well.

Like 99.999% of the time well.

I had considered porting it to PowerShell but why – it was working and had done for 5 years with minimal updates AND later this year we’re migrating the deploys to Octopus Deploy.  Hooray.

So if it ain’t broke don’t touch it..?

Except yesterday for the first time in 3 years it had to be changed.

Slightly.

I can’t migrate it to Octopus Deploy yet and I knew the process would work sweet as with 2 lines consisting of:

dir %DOTNET_MISC_LOCN%\%DOTNET_ARTIFACT_NAME%* /b >%DOTNET_MISC_LOCN%\%artifactversionfile%
for /F "delims=;" %%I in (%DOTNET_MISC_LOCN%\%artifactversionfile%) do <awesome stuff>

I know, I know it’s fairly basic stuff here — but it solved an interesting conundrum I had for the client’s situation that will be rare but we don’t want to do manual stuff.

I made the edit, did a quick test and today it did what it was supposed to do.

First time.

And that is why at times when we look at how to solve a problem if the process works — it doesn’t have to be the latest greatest tools.

It can be simple old scripts that do fairly simple  stuff yet those scripts result in the goal of automating your deployment process so that we achieve repeatable, reliable releases to our systems.

So focus on the goal, don’t get too hung up on the Tools bit. Your Process will define the results of your efforts. As will the People who have embraced the Culture that is necessary to make stuff go.

Yip.