Improving Local Development Workflow With Go Task
|Nov 04, 2020||Consider the Benefits of Powershell for Developer Workflows|
|Nov 03, 2020||Improving Local Development Workflow With Go Task|
Development workflow, especially outside of a full-fledged IDE, is often a disjointed affair. DevOps oriented workflows that often combine cli tools such as terraform, PowerShell, bash, and more all provide more complexity to getting up to speed and productive.
Currently, there is a variety of frameworks to solve this problem. The “gold standard” most are familiar with in the open-source community would be Make.
This is not an exhaustive list, it’s focused more on my journey, not saying that your workflow is wrong.
I’ve looked at a variety of tooling, and the challenge has typically that most are very unintuitive and difficult to remember.
Make…it’s everywhere. I’m not going to argue the merits of each tool as I mentioned, but just bring up that while cMake is cross platform, I’ve never considered Make a truly cross platform tool that is first class in both environments.
The thing is, not every environment will always have PowerShell, so I’ve wanted to experiment with minimalistic task framework for intuitive local usage in a project when the tooling doesn’t need to be complex.
InvokeBuild is incredibly flexible and intuitive, there is an expectation of familarity with PowerShell to fully leverage.
If you want a robust framework, I haven’t found anything better. Highly recommend examining if you are comfortable with PowerShell. You can generate VSCode tasks from your defined scripts and more.
Psake aren’t great for beginners just needing to run some tooling quickly in my experience.
The power comes with additional load for those not experienced in PowerShell.
If you are needing to interact with AWS.Tools SDK, complete complex tasks such as generating objects from parsing AST (Abstract Syntax Trees) and other, then I’d lead towards
However, if you need to initialize some local dependencies, run a linting check, format your code, get the latest from main branch and rebase, and other tasks that are common what option do you have to get up and running more quickly on this?
I’ve been pleasantly surprised by this cross-platform tool based on a simple
It’s written in go, and as a result it’s normally just a single line or two to immediately install in your system.
Here’s why you might find some value in examining this.
- Cross-platform syntax using this go interpreter sh
- Very simple
yamlschema to learn.
- Some very nice features that make it easy to ignore already built assets, setup task dependencies (that run in parallel too!), and simple cli interactivity.
My experience has been very positive as I’ve found it very intuitive to build out basic commands as I work, rather than having to deal with more more complex schemas.
The docs are great for this project, so I’m not going to try and educate you on how to use this, just point out some great features.
First, with a quick VSCodee snippet, this provides you a quick way to bootstrap a new project with a common interface to run basic commands.
Let’s give you a scenario… assuming you aren’t using an already built Docker workspace.
- I need to initialize my 2 terraform directories.
- I want to also ensure I get a few go dependencies for a project.
- Finally, I want to validate my syntax is valid among my various directories, without using pre-commit.
This gets us started…
Next, I threw together some examples here.
- Initialize commands for two separate directories.
fmtcommand to apply standardized formatting across all
- Finally, wrap up those commands with a
dep: value that will run the
initcommands in parallel, and once that is finished it will run
fmtto ensure consistent formatting.
You can even add a task in that would give you a structured git interaction, and not rely on git aliases.
I’ve seen many folks online comments about why even bother? Can’t the dev just run the commands in the directory when working through it and be done with it?
I believe tasks like this should be thrown into a task runner from the start.
Yes, it’s very easy to just type
go fmt, or other simple commands… if you are the builder of that project.
- it increases the cognitive load for tedious tasks that no one should have to remember each time the project grows.
- It makes your project more accessible to new contributors/teammates.
- It allows you to simply moving to automation by wrapping up some of these automation actions in GitHub Actions or equivalent, but simply having the CICD tooling chosen run the same task you can run locally.
Minimal effort to move it to automation from that point!
I think wrapping up things with a good task runner tools considers the person behind you, and prioritizes thinking of others in the course of development. It’s an act of consideration.
Here’s how I’d look at the choices:
- Run as much in Docker as you can.
- If simple actions, driven easily on cli such as build, formatting, validation, and other then start with
Taskfrom the beginning and make your project more accessible.
- If requirements grow more complex, with interactions with AWS, custom builds for Lambda, combined with other more complex interactions that can’t easily be wrapped up in a few lines of shell scripting… use
InvokeBuildor equivalent. This gives you access to the power of
.NETand the large module collection provided.
Even if you don’t really need it, think of the folks maintaining or enabling others to succeed with contributions more easily, and perhaps you’ll find some positive wins there. 🎉