Subscribe
Share
Share
Embed
Something different for this episode! A live recording of my thoughts on integrated vs isolated dev environments.
Show Notes
If you enjoyed this format then tweet me @adman65 or @smallbatchesfm.
★ Support this podcast on Patreon ★
Creators & Guests
What is Software Delivery in Small Batches?
Adam Hawkins presents the theory and practices behind software delivery excellence. Topics include DevOps, lean, software architecture, continuous delivery, and interviews with industry leaders.
First off, what you’re reading is not a transcript. It’s cliff notes.
I did something different for this episode. Typically I write and edit the scripts. I write the episodes to be nutrient dense. I want the episode to bring to a top percentile understanding of a topic that you can apply in your daily work. That format works well when can I provide the gist of a topic without much talk of trade-offs or other nuances.
This topic didn’t fit the model so I recorded the episode live. As a result there is no transcript, so here’s the cliff notes.
Teams must choose between integrated and isolated dev environments. The choice has deep ramification on the engineering team. Each has it’s trade offs although there’s a clear winner in my view.
The isolated approach uses fakes to replace external dependencies in the development environment. The fakes may be maintained by the consumer team or provided by the service team. This model provides maximum autonomy to engineers since they’re only focused on the codebase in question.
The trade-off is that it requires strict engineering disciple to maintain boundaries to support fakes in dev, mocks in test, and real versions in production.The isolated model also stipulates that services can be developed and tested with necessary confidence fore production deployment without manual testing in an integrated environment.
The integrated model assumes that a service accesses functioning versions of all dependent services. If service-a requires service-b , then service-b will be running and accessible to service-a. This implies that service-b uses the same assumptions, so all of service-b’s dependencies must be running as well. In other words, starting a fully integrated environment to support developing one service. This provides developers immediate feedback from and end-to-end level.
The trade-off is complexity and murky ownership. This approach assumes that each services provides a start script, then developers can run those start scripts in the proper sequence to create a functioning environment. This also requires developers to familiarize themselves with all services for proper wiring up, debugging, and troubleshooting.
I prefer isolated environments. I explain why in this episode.