A lot of teams have moved from being colocated to distributed recently, and quite a few people are jumping in to defend their tool of choice for representing “cards on a wall.” Jira-bashing is always popular, but one thing I’ve noticed is that folks aren’t necessarily optimizing for the same things; the result can often be a focus on tooling, and reducing the discussion to “which board is better”, rather than understanding what problems these tools help us to solve.
Continue reading

Note: This post was originally published on our company site, which has since been taken offline. The last half of 2019 brought some big changes for us at Digital Solutions: We had a team member leave, and we also saw substantial growth. That meant needing to hire four new folks, taking our team of six to ten. As a small, bootstrapped company without a dedicated hiring manager, we have to prioritize our hiring and make room for it in our daily work; at the same time, our size gives us a lot of freedom to experiment with our hiring practices.
Continue reading

Note: This post was originally published on our company site, which has since been taken offline. This is an experience report from our team, who first dabbled with mob programming two years ago; since then we have adopted it as part of our core culture, and continue to spread it throughout our organization and clients. We talk a bit about who inspired us, how we convinced our leaders to let us try it, and where we ended up.
Continue reading

Azure Functions are Microsoft’s serverless offering, and they can be a great option for building simple, scalable applications and APIs. A common practice is to apply a CNAME with your custom domain to the Azure DNS entry, and have users access your application from that domain, “hiding” the implementation. Today HTTPS is necessary, and Azure has built-in capability to apply a custom domain and certificate to your Function App. If you want to get your certificates from Letsencrypt, there is a site extension by Simon J.
Continue reading

In a previous post I outlined a workflow to create and trigger a pipeline job in Jenkins whenever a git tag is pushed. A common step in this type of workflow is to deploy to a staging environment once all the build and test steps are successful. One way to accomplish this is by using parameters–a typical (declarative) job definition might look like: pipeline { agent { label 'myLabel' } parameters { choice(choices: 'staging\nproduction', description: 'Which environment?
Continue reading

There seem to be a lot of questions around making Jenkins pipelines work with git tags; having set this up recently, I thought I’d write a quick summary of one workable approach. Workflow This post covers a specific workflow used by my team; in particular, we don’t do pull requests, and we use tags to denote releases, which are automatically deployed. We tag our releases manually, so we aren’t configuring Jenkins to tag every build, but rather to watch for new tags to be pushed, and execute builds for them.
Continue reading

I came across a situation recently where secrets were being leaked via SaltStack deployments, run from a CI job. I’ll explain how this can happen, and give some suggestions to reduce the risk. A common workflow in SaltStack is to store secrets in a pillar on the salt master, which allows data to be encrypted until compilation. The file.managed module can then be used to templatize configuration files and inject secrets from the encrypted pillars.
Continue reading

I recently did some work on a somewhat neglected C# code base; the basic function of the application was to pull down some custom reports from a third-party web API, parse the results, and store them in a database. There were a few obvious design problems, and the application hadn’t been built or deployed in years, but it did include a small test suite–around 50 unit tests, written with Microsoft’s testing framework.
Continue reading

The past few weeks at work, I’ve been building out a process for automation of a Microsoft Tabular Model project; in a previous post I described how we automated the deployment process, and this post will focus on testing. A full, working sample project is available on GitHub. The Problem: Testing Measures In SQL terms, a measure is somewhere between a view and an analytic function; it’s a calculation used to dynamically aggregate and filter report tables, and it can contain a fair bit of logic.
Continue reading

My team recently starting using Microsoft’s Tabular Model databases at work, as an intermediate layer between an operational data store and the end users who consume this data from Power BI. Tabular Models are an OLAP technology, providing an in-memory data cube, with measures being defined using either MDX or DAX query languages. As we were learning about the stack, we realized that there wasn’t much documentation around automated deployment or testing of Tabular Models; the typical deployment story seemed to be “right click -> publish” from Visual Studio.
Continue reading