Goal: setup PowerShell Core and .NET for development in Ubuntu running in Windows subsystem for Linux (WSL). And a few other tools.
Motivation: porting PowerShell scripts for .NET development on Linux, thus enabling more programmers to develop on a certain codebase and enabling use of Linux-based containers for continuous integration and testing.
Author Neal Stephenson, in his essay "In the Beginning... Was the Command Line," memorably compares our graphical user interfaces to Disney theme parks: "It seems as if a hell of a lot might be being glossed over, as if Disney World might be putting one over on us, and possibly getting away with all kinds of buried assumptions and muddled thinking. And this is precisely the same as what is lost in the transition from the command line interface to the GUI. (p52)
With new programmers whose experience has been entirely mediated through an
IDE like Visual Studio or Eclipse, I have sometimes wondered if they are understanding the "buried assumptions" and suffering from "muddled thinking" due to their lack of understanding of the basic command line operations that underlie the automation provided in the IDE. I still recall when I was that young developer, who had started with nothing but the command line, and realized that Visual Studio had crippled my ability to know how to build and test .NET Framework solutions (setting up an automated build process in Cruise Control helped cure me of that).
"Infrastructure as Code", or IaC if you prefer TLAs, is the practice of configuring infrastructure components in text files instead of clicking around in a user interface. Last year I wrote a few detailed articles on IaC with TeamCity (1, 2, 3). Today I want take a step back and briefly address the topic more broadly, particularly with respect to continuous integration (CI) and delivery (CD): the process of automating software compilation, testing, quality checks, packaging, deployment, and more.
This summer, one of the development teams at the Ed-Fi Alliance has been hard at work building Project Buzz: "When school shutdowns went into effect across the country as a result of COVID-19, much of the information teachers need to support students in the new online-school model had become fragmented across multiple surveys and the Student Information System." (Fix-It-Fridays Delivers Project Buzz, A Mobile App to Help Teachers Prepare for Back-to-School).
As project architect, my role has been one of support for the development team, guiding technology toolkit choices and supporting downstream build and deployment operations. The team agreed to develop the applications in TypeScript on both the front- and back-ends. My next challenge: rapidly create TeamCity build configurations for all components using Kotlin code.
While the Ed-Fi Alliance has made investments to improve the installation processes for its tools, it is still a time–consuming task: easy to get wrong, you must have the right runtime libraries, and it is problematic to have multiple versions running on the same server.
What if end-users could quickly startup and switch between ODS/API versions, testing out vendor integrations and new APIs with little development cost and with no need to manage runtime dependencies? Docker containers can do that for us.
Continue reading on ed-fi.org…
I don't like having a single large file for a TeamCity project, which is the default when exporting a project. It violates the Single Responsibility Principle (SRP). For maintenance, I would rather find each element of interest — whether a sub-project, template, build step, or vcs root — in its own small file, so that I don't have to hunt inside a large file. And I would rather add new files than modify existing ones.
This note about non-portable DSL explains the basic structure when you want to use multiple files. And yet I never noticed it while hunting in detail for help on this topic a week ago; only just stumbled on it while writing this blog piece. It seems to imply that using multiple files is "non-portable," but apparently I have been using the portable DSL: "The portable format does not require specifying the uuid", which I've not been doing.
There is a small risk that I could do something drastic and lose my build history without a uuid. Since I also have server backups, I'm not too worried. And in all of my experiments I've not been able to find any problems with this approach so far.
Infrastructure-as-code (IaC) is the principle of configuring systems through code instead of mouse clicks (cf Packer Tips and Lessons Learned for another example). TeamCity, the popular continuous-integration (CI) server from JetBrains, enables IaC through writing scripts to interact with its REST API, or by storing projects settings in version control. This article will share some lessons learned in using the Kotlin DSL for project settings. These will include:
Packer is a cross-platform tool for scripting out virtual machine images. Put another way: use it to create new virtual machines with fully automated and repeatable installations. No clicking around. Some of the benefits:
Recently I installed MongoDb using Chocolatey, and was surprised to notice that the executables weren't placed into the Chocolately path. Chocolatey uses a shimming process to automatically add executes to PATH. This is really quite nice.
I can imagine scenarios where I have command line executables that weren't installed by Chocotely that I would like to add to my path easily. Or a scenario like this where I want to address something that someone forgot to build into the choco package. Thankfully manually calling the shimgen executable to create a new shim is quite trivial:
c:\ProgramData\chocolatey\tools\shimgen.exe `
--output=c:\ProgramData\Chocolatey\bin\mongodump.exe `
--path="..\..\..\Program Files\MongoDb\Server\3.6\bin\mongodump.exe"
The only key thing to notice is the relative path constraint.
One of my very first technical blog posts was about running OpenSSH on Windows - written over 14 years ago. Recently I was playing around with Microsoft's port of OpenSSH, which has officially achieved version v1.0.0.0 beta status. Installation was pretty easy, but I ran into a little problem: needing to set "user" group permissions. This little gist has my final script. For reasons of my own I didn't feel like running the chocolatey install, so I don't know if it has this permission problem.
