Common Libraries for Automation Tasks

Automation is to DevOps as a telescope is to astronomy.

Besides black art, there is only automation and mechanization.

Federico García Lorca (1898–1936), Spanish poet and playwright

I created Azure DevOps Custom Pipeline Tasks for a while. In time environment types, I work on increasing, and automation has to move to those new environments. Now I have Azure DevOps tasks, GitHub Actions, Multi-stage Docker Images, and Windows and Mac Developer laptops. Not all automation needs to reach everywhere, but there are good use cases for almost all of them under all environments. 

Different applications can use the same functionality, which could be released using GitHub or Azure DevOps. An agent or a multi-staged docker image can generate the release artifacts. 

Developers and DevOps people also may want the same functionality on their computers. My solution to this problem is simple. I picked two languages that Framework installed almost everywhere. I have built Common Libraries for the functionality shared across. 

Then I create Actions, Azure DevOps Tasks, and Cli tools to use the functionality which have already been built on Common Module. 

This pattern is not new and used by developers for everything we do, but when I check CLI tools, Tasks, and Actions, I don’t see many examples of Common libraries. What I have built contains two platforms Node.js and Dotnet. For some projects, a single platform could be enough. This makes development and maintenance easier. But for other environments like mine, a single solution can’t spread over all the places it needs to run. 

Pick the platforms after assessing your needs.

Common Library:

Check out the git repo: https://github.com/mmercan/VulnerabilityScanner/tree/main/VulnerabilityScanner.Node.CommonLib

 Keep all your application logic here. You may have different functions for different environments, save them in the Common Module (like printing the results in color or not), or export HTML files for the results app gathers. You can use public or private NPM repositories to store your package. Versioning will be important as you may need to upgrade some of the functionality in time.  

If you haven’t created a node module, this article from Carl can help https://itnext.io/step-by-step-building-and-publishing-an-npm-typescript-package-44fe7164964c

GitHub Action 

Check out the git repo :https://github.com/mmercan/actions-vulnerability-scanner

GitHub Action requires a separate repository. Just use the GitHub Action template and create a new repo, “Use this template” button can help with this. (https://github.com/actions/typescript-action), some of the dependencies are deprecated and need an update. Code side, there may be some situations you may need to translate your GitHub action inputs and outputs to your Common Library, like file locations.

AzureDevops Build Release Task

Check out the git repo: https://github.com/mmercan/VulnerabilityScanner/tree/main/VulnerabilityScanner.Node.ADO.Task

Building Azure DevOps Task in the Azure DevOps pipeline makes sense. Azure DevOps have specific tasks, that can help you version and package your application. You can consume your GitHub repository in Azure DevOps pipelines. You will keep all code in one location but also can use the benefits of the Azure DevOps pipeline on release.

 Cli

Check out the git repo: https://github.com/mmercan/VulnerabilityScanner/tree/main/VulnerabilityScanner.Node.Cli

Translating command line arguments to Common Libraries’ input will be the challenging part of the CLI development. There are good libraries to ease this. I prefer commander (https://www.npmjs.com/package/commander)

This is my scenario