The Journey Begins

Thanks for joining me!

Good company in a journey makes the way seem shorter. — Izaak Walton

About this blog

I have been a programmer for a very long time, and have learned a few things getting here. I want to share those things.

For the last few years I have been working on a challenging project, upgrading my employer’s Continuous Integration process. Being a Microsoft shop, the powers decided to use Microsoft products unless there is something much better for out needs.

Thus each developer is expected to use Visual Studio as the primary development tool, and Azure DevOps for team management, builds and releases. We have a lot of reuse, so components are distributed internally using NuGet.

NuGet is great for sharing components and version control. NuGet is also a challenge because it does not have native support for SQL Server or PowerShell projects. That is a problem because we are predominantly a database shop. SQL Server projects and their build targets, dacpac packages, are excellent for building database applications with many components.

My role is CI Architect, and I designed a VS database solution template. It includes custom support for consuming and publishing database packages. The aim is to make the development experience the same for all our developers.

Choices made

The old CI process depends heavily on PowerShell scripts. Having to support those assets, I decided to stick to PowerShell with the new process.

My other choices follow from my background as a programmer.

• I like small, focused routines
• I like modular designs
• I like reuse
• I like Test Driven Development (TTD)
• I like the safety of source control
  • I am particularly fond having my routines individually under source control
• I like encapsulating external resources
  • I like making them replaceable, say Subversion with Git, Azure DevOps with other frameworks

Coming up

The next blogs will be about these decisions, and how they manifested in PowerShell.

Advertisement