With the reoccurring need of PowerShell to manage infrastructure setup, monitoring and deployment, it's vastly important that we have the right tools in place in order to keep PowerShell scripts organized and properly maintained. Nowadays, the development of software applications require a common set of strategies/practices so developers can feel confident about making new changes and/or refactoring existing code. Techniques like test-driven development are quite common in the object-oriented programming world. Unfortunately, when it comes to infrastructure code, developers tend to ignore the same strategies. Mostly due to time constrains or the lack of reliable tools to test PowerShell, Shell or Batch scripts.
As you might have noticed, I have been absent from this blog from the last couple of months. Not that I ran out of topics or I don’t want to share my opinions, it’s just “life got in the way”. Putting it bluntly, my priorities shifted so I choose to spend more time doing other tasks. Obviously, I could spare a few minutes here and there to write a new blog post, but sometimes you just need a long period of reflection to observe and rethink what to do next.
OpenSSL became publicly known (unfortunately) for the wrong reasons. Their development team got the typical backlash that System Administrators usually get: if everything is working fine nobody cares, as soon as something bad happens everybody loses their mind. I'm obviously talking about the Heartbleed bug. Before Heartbleed was found, it was estimated that 61% of all Apache servers used OpenSSL to handle TLS/SSL connections. As soon as it was found a lot of people freaked out. Successfully using this exploit could allow an attacker to read a target server memory, extract its private key and ultimately mount a man-in-the-middle attack . On the other hand, OpenSSL development team consisted of 11 contributors and a budget of less than $1 million a year (most of it from donations). In a world where even large Corporations, with almost unlimited resources, consistently release buggy software, a team of eleven developers should be allowed to make a few mistakes.
The first step of any robust development workflow relies on a structured and well-defined build process. Having a manageable build process can spare your development team from wasted time, headaches and unnecessary complexity. If you're handling a handful of projects with low compilation overhead, this particular topic might be irrelevant to you. Today's article is mainly targeted for those who must work with multiple projects, of different kinds (Web applications, Scheduled tasks, Console applications, Mobile application, database script, so on) and deploy multiple artifact types.