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