While working, together with Siebrand, on a project he planted the DevOps seed/mind-bomb in the storm of thoughts in my brain. This opened up a whole new world for me; Everything and everywhere is code!
While getting acquainted with this new way of working i must admit i felt some internal resistance; I just want to code! Over time, while diving into The Phoenix Project, i understood that “I just want to code!” isn’t going to cut it. There has to be a higher purpose to the script that i am creating. All scripts should have a common denominator. The reason that i am making a tiny script should address a common goal. Having this in mind, Siebrand and I, started working on assembling scripts into a library of functions. Each function has it’s own purpose and can be easily reused over multiple script. Well, doesn’t it make it more complex? Actually there is a thin layer of complexity over this, however this opens the gates of uniformity. Now all subjacent script will make use of common functions. For instance creating a log file and rotating those log files to prevent the server to clog up. Now all script will make use of this function and the log files are created in the same syntax and have a configurable rotation scheme.
Having this concept in mind we needed to make sure that our library will remain available and that a new function in our library wouldn’t jeopardize our other coding. It is time for versioning of our code. We opted for getting the code checked into the Microsoft Azure (GIT) repository and start using another editor. Siebrand and most other IT co-workers are used to PowerShell ISE. However the ISE is shipped with Windows the PowerShell ISE is no longer in active feature development and there is no support for the ISE in PowerShell v6 and beyond. I was happily content with using PowerGUI from
Quest Dell Quest Software is not on the product list nor being developed anymore. This is certainly not future proof so we head our for a complete IDE environment and we discovered that Microsoft Visual Studio Code was the answer. It has everything we need; multi-platform, community driven, open source, vast majority of extensions, version control, debugging and code linting. Heading out to Microsoft Visual Studio Code!
Our VScode tool chain
VScode also has seamless integration with Microsoft Azure DevOps Services. This enables you to check in code based on GIT.
It’s also possible to use the widely used GitHub, which has been cleverly acquired by Microsoft recently. GitHub is a smart concatenation of two syllables; Git and Hub.
Git is a distributed version-control system for tracking changes in source code during software development. It is designed for coordinating work among programmers, but it can be used to track changes in any set of files. Its goals include speed, data integrity, and support for distributed, non-linear workflows.
Hub in GitHub represents the HQ for people to share their work, interact with each-other and ultimately create better software together. However GitHub can be used by anyone, not only by software developers!
When gluing the concepts together a foundation has been formed for source code versioning and collaboration, either publicly or privately.
Getting things done (more efficiently)
From all the daily tasks that i have to complete during the day i need to focus on the things that bring to most value to the customer. This isn’t necessary always adding features to current solutions but can also mean shortening the process time for activities, either by creating an automated workflow or making the workflow more optimal when it comes to getting things done. Ideally the work we put into automating will pay down on the technical debt and thus increasing the overall efficiency.
The four types of work
The three ways
The five ideals
Tool chain – required software
- Git for Windows
- Github Desktop
- Visual Studio Code
- Visual Studio Code extensions;
Setting up the environment