Writing Deployable Code (part one)
Yes, you could be like this gal; or maybe you already are; I know at least I used to be, emmm still probably am, sometimes…
Anyway, the title reads Writing Deployable Code, well — any code could be deployed, a ninja ops can deploy the least deployment-friendly codebase you could think of, however, what happens when it’s not a ninja ops on the wheel, what happens when it’s just you or me? Any code is deployable, it’s just that sometimes it’s notoriously difficult to deploy code that isn’t showing the least effort of trying to get itself deployed, that isn’t deployment-friendly. What does deployment-friendly mean? Let’s figure that out next.
This article has three parts. Part one describes a little bit of the motivation and general context. Part two describes the basic features that deployable code needs to support and part three lists some more advanced topics for making your code deployment friendly.
A lot had been written about Writing Testable Code (Example [PDF]). And in most cases, the side benefit of writing testable code is wonderful — you not only get to be able to test your code, but — as a bonus, it turns out, one of the most significant side effects of testable code is that — it’s just better code; tested (testable) code is modular, tested code is reusable — not so much b/c it’s “bug free”, but more because code that isn’t modular is just plain simple, harder to test.
But what does Deployable Code mean? What does one (developer) needs to keep in mind while writing code, that could make this code easier to deploy?
This post comes naturally to “backend developers”, or “full stack devs”, however, I think that at least in some cases frontend devs could also learn from it, perhaps mobile app devs as well; In the general sense, however, when I refer to “deployment” what I usually have in mind is a server side service, e.g. written in Java, Scala, Go, Ruby, Python or what have you, running on one or more hosts, either a virtual host running on EC2 or the likes or your own physical hardware.
I come naturally to this topic as a backnend, frontend, full stack developer, a continuous deployment enthusiast, and finally — devops advocate. As someone developing web services for more than a few years, as someone who’d developed a few non-trivial continuous deployment systems, as someone who spends about 50% of his time on developing systems (aka dev) and the other 50% on provisioning, deploying, monitoring and scaling the same services (aka ops). Having one foot in dev and the other in ops provides a very nice perspective of what’s really required when writing deployment friendly code.
There are two catalyst for the importance of writing deployable code now-days. First, all this continuous deployment and devops story makes everyone (devs and ops) concerned about implementing deployment the right way. If you’re going to do this 100 times a day, you better do this damn right. The other factor is the microservices approach, which tends to move the complexity from developers to ops in the sense that they make each and every service simple but the integration of all these services into a meaningful fabric (a usable app) becomes far more challenging. (source: http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html). In light of these, writing deployable code becomes a necessity.
This is the end of part one. In this part I provided some background and motivation for why is it important to write deployment friendly code.
In part two I will list the basic methods for making your code deployment friendly and in part three I will list some more advanced methods.
Stay tuned…
