Why Implement Self Service Infrastructure
One of the many concepts of DevOps is the self service aspect of procuring new infrastructure for teams to work with. I think there are a number of ranges that these particular concept can be implemented. It can be from giving people direct access to their organizations cloud provider's . . .
I've been working on a new version of dotnetzero (formerly psakezero). This v2 version has a number of changes that were fun to build.
Large refactoring into smaller PowerShell functions
I'm trying out an approach that takes each PowerShell function and places them into their own file. This was for a couple . . .
Using YAML to define your builds
In a previous post I talked about high-level and somewhat generic approaches to getting your CICD pipeline to be responsible for more than just your builds but also you infrastructure deployment.
Now I'd like to walk though a an actual implementation of a build definition as . . .
What is a build definition as code?
The concept of a build definition as code as it relates to a build server for continuous integration means using an actual declarative language to define how your build should works instead of using a web user interface to define your build steps. You can use a general purpose programming language, . . .
I seem to get a lot of source control, build and other CICD content in front of me during the course of a day. One of the reoccurring themes that comes up occasionally is against feature branching. The argument usually suggests the following approach.
when doing feature branching your CI stands for "continuous . . .
Your CI build has a hidden flaw
After you get your new continuous integration build initially configured you get to sit back and enjoy the fruits of your build labor. You check in your code and watch your build pipeline magically spring into action. As you progress you might add a branch spec or two and now you are down the . . .
Posted in: cicd