Deployment fidelity and the unmelodics #
When I first read this post about Deployment fidelity I was so amazed by the metaphor that it really printed my memory. I was an indie developer at that time that was creating software basically as an artisan: Using the cloud only to have it running and hosted. Not much interaction with other developers except on occassional contributions to open source dependencies of my software. Thus, I had always under control all the software I was running in a project and for the nature of how I was developing it, I could run it all in my own computer or in "the target".
I thought this was the usual and common way to develop software. I could think of no other way not better or worse, no other and this one was melodic enough.
Well, turns out it isn't and they're apparently far less melodic. That there's these other ways is not the actual problem, though. The problem is the fauna that lives in these caves really loves this unmelodic environment because of how much unproductive it is.
Key Techniques #
Is this pesimistic enough?. Well, let's mention what would be the key development techniques that increase the fidelity and compare them to what the unmelodics do. This would be a guide on how not to apply those techniques on your development process.
Technique | Description | Advantage | Unmelodic |
---|---|---|---|
Local development | The developer can run tests and an instance of the software in its own equipment | Fast feedback | Misuse CI/CD infrastructure to test any change instead |
Trunk based development | All commits in Master are productive. Master is the only deployable version of the software. | Faster integration and deployment | Work in long-living branches that require effort to integrate |