Last time I touched upon the subject I wrote about downright avoiding additional code - because everything has a cost. There, however, is one genuine exception: one should aggressively automate the deployment pipeline from the very first moment regardless of the type of the project. Even if it is just a throwaway script, put in mechanisms that automate environment setup and possible installation and configuration. A year later, when something breaks and it needs to be tweaked you have your automation to lean on to as a form of documentation (careful commenting is also recommended).
I’ll show a specific example I’ve used in a project where a cross-compilation environment on a server is used to build up a device image and then I flash the device image locally on my dev computer:
.phony: clean all: backup clean makeatserver cpfromserver cptodevice makeatserver: ssh -t server 'cd /path/at/server/repository && git submodule update && git pull --rebase && make' cpfromserver: scp server:/path/at/server/build/bin/*.bin /localpath/devicebins && scp server:/path/at/server/build/*.dnl /localpath/devicebins && scp server:/path/at/server/build/*.bin /localpath/devicebins cptodevice: customcommand flash device clean: rm -rf *.bin *.dmp *.hex *.list *.map *.elf *.dnl backup: mkdir -p previous && [ -f flashimage ] && cp *.bin previous/ || echo "no files to backup"
This is part VI of my series of What do you Believe in as a SW Developer? // Timo Koola