18 posts tagged with "sdlc"

"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.

Should bugs and spikes receive story points to aid in sprint capacity planning? Some teams will estimate all work items by time during sprint planning in order to find the right commitment. Many teams hate this and/or spend an inordinate amount of time arguing about time. Those that abandon time may be tempted to put points on these unplanned, non-productive items, but there is a cost: the completed velocity will overstate the projected release timeline for the remainder of the release backlog.

Possible solution: track the ratio of story to non-story points and use that to pad out the release projection estimate.

Motivation​

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.

Is This a Good Idea?​

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:

1. What is Kotlin?
2. Benefits of using Kotlin
3. Learning Kotlin from TeamCity
4. Debugging before committing
5. Managing secure data
6. Connecting to forks

There is a positive a trend of developers doing more of their own testing, going beyond unit testing. However, if independent testers are cut out of the loop, then surely many applications will suffer. Case in point: a user unexpectedly entering a decimal temperatures and military time in a citizen science data collection application.

The TERN data collection application supports the Texas Estuarine Research Network's citizen science efforts on the Gulf coast of Texas and has been in operation since 2016. The code and testing were 99% all on my own, in spare time on weekends. I had tried to recruit some help with this open source project, but other than a couple of early code commits, I was unsuccessful in that regard.

Tutorials​

Git is a fabulous tool for source control management. While incredibly powerful, it can be a little daunting to learn at first. The following tutorials will help. They are organized from basic to more advanced.

Recently I was talking with a friend and extolling the virtues of using NuGet packaging for application and web site deployments - and I nearly forgot the core advantage: dependency management. It is all fine and well to have a fancy zip file, relabeled as .nupkg. You get the benefit of version control on the package itself, and you get the nuget.exe or choco.exe installer (or coming soon, OneGet).

But the most important piece is this: you don't have to bundle your dependencies with your installer package. You just need to "wire" them up properly in the .nuspec specification file, and make them available. Now, let's talk about managing those packages.

NuGet has been helping .NET developers maintain package dependencies for a number of years now, and any good dev should know the basic operations from within Visual Studio – how to add, update, and remove packages in a solution, using the NuGet Gallery. But to use only the NuGet Gallery is to know only half – or less – of the story. You might be missing out on…

• Testing out pre-release versions of your projects key dependencies.
• Reverting to older versions of libraries.
• Stand-alone tool installations using NuGet.
• Full-fledged Windows installations using Chocolatey.
• Placing your custom packages into private repositories.

Here are a few tips for moving toward mastery of this crucial part of the .NET development ecosystem.

Last year I read Jurgen Appelo's Management 3.0: Leading Agile Developers, Developing Agile Leaders. Despite taking many useful notes, I did not have the time to write up a full review / collect my thoughts on it. Overall impression: this books has tremendous value, and I recommend it highly to anyone in IT management / leadership (whether operations or software).

I look forward to re-reading it in the near future. For now, I will satisfy myself by re-collecting and re-pondering a few of those notes, starting with the topics of Knowledge and Diversity (from Ch 4 - The Information-Innovation System)