It has been interesting to read the recent assertions that a more effective way of building, testing and delivering applications and databases is to use toolchains rather than a single comprehensive tool. A toolchain, in this context, is a set of specialist software tools that run in sequence, taking as input the result of the previous tool, and passing on its output to the next. They are used mainly for automating software processes that require a number of steps.
This certainly beats the point 'n' click approach hands-down, but the toolchain is really only a way to "put a toe in the water". We need to use this technique to get familiar with the best way of using the command-line interface, and appreciate pipelines, streams, error-handling and logging. However, it is rather vintage. This sort of technology was baked into UNIX from the start and was familiar in MSDOS v3. Even CP/M had a primitive but usable batch system. Life in IT has moved on.
Microsoft’s thinking about automating processes in Windows was once curiously apathetic. The batch in Windows NT was single-process, arcane and commonly referred to as a "world of pain". It could do surprising things but only if you were lucky or very proficient. Thanks to some ex-Linux visionaries within Microsoft, however we got PowerShell. One of the drawbacks to BASH scripting – well, and all UNIX scripting – is that it passes data through the pipeline as text, and there is no standardised way of passing data as objects. PowerShell, on the other hand, passes data as objects. PowerShell has advanced well beyond what is possible in the traditional toolchain. It is now able to manage complex processes as a workflow.
I reckon that are two great advantages of a workflow. You can run several processes at once, and you can run them more easily on other machines. You can nest processes, you can suspend and stop them, and a process will even survive a reboot. There is a downside, which is that it is a cultural shift, and we know from the maturity of workflow techniques that IT people have been nervous of adopting workflow. However, some database tasks, such as ETL, cry out for workflow: It is obviously suitable for delivery. We talk glibly about the serial pipeline for delivery but wherever and whenever I’ve done it as part of a team, the process map looks more like spilled spaghetti.
If your pipelines are blocked, then perhaps workflow is the "drain-rod" that will make your DevOps processes flow.
