Software Architecture Books Summary And Highlights -- Part 12 Code Base Management
Code Base Management
Highlights
Version controls and branch management
branches are a drag on productivity. In many cases we think complex branch and merge strategies are a perceived safety crutch—an attempt to keep trunk stable. As we see throughout this book, there are other ways to achieve that outcome.
Long-Lived dev Branches are expensive to maintain and sync
developers must not have a choice when adding a dependency onto some library that is already in use in the organization.
One native advantage of a many repo approach is that separate repositories are obviously capable of having different sets of authorized developers, visibility, permissions, and so on. Stitching that feature into a monorepo can be done but implies some ongoing carrying costs in terms of customization and maintenance.
VCSs will focus on allowing larger repositories with better performance scaling, but also removing the need for larger repositories by providing better mechanisms to stitch them together across project and organizational boundaries.
There are an increasing number of VCS and build system facilities that allow you to have both small, fine-grained repositories as well as a consistent “virtual” head/trunk notion for the whole organization.
SWG Ch 16 version controls and branch management
Build system
The dark side of task-based build systems
The problem with such task based systems is that they actually end up giving too much power to engineers and not enough power to the system. Because the system has no idea what the scripts are doing, performance suffers, as it must be very conservative in how it schedules and executes build steps.
Difficulty of parallelizing build steps
Difficulty performing incremental builds
Difficulty maintaining and debugging script
Artifact-Based Build Systems
Engineers would still need to tell the system what to build, but the how of doing the build would be left to the system.
able to trivially parallelize such programs and make strong guarantees about their correctness that would be impossible in an imperative language.
tradeoff:
DIY approach is easy for small projects
Task based approach is scalable and flexible
Artifact based approach is further scalable but less flexible migration from an existing task-based system can be difficult and is not always worth it if the build isn’t already showing problems in terms of speed or correctness.
one of the more surprising lessons that Google has learned is that limiting engineers’ power and flexibility can improve their productivity.
SWG Ch 18 build system
Deployment metrics
- cycle time is the pace of progress through the pipeline
- traceability: is the ability to recover all of the artifacts that led to an element having a problem. usually data stored in db
- Repeatability is getting the same result when you perform the same action with the same artifacts. maybe hard to achieve due to dependency upgrade
SAP ch 5 Deployability
Some interesting Deployment Tactics
- scale rollout: gradually release to all users
- deploy different versions of service at the same time.
- package all dependency into source code’s binary
- feature toggle
SAP ch 5 Deployability
One repository and multiple builds per service cons: it encourages making change to multiple services at once which could increase coupling
MSV Ch 6 Deployment
In transitive process, when services boundary haven’t been settled down, it is fine to put multiple services into same deployment target if they are changed together frequently. But you need to eventually decide the boundary and create one deployment per service.
MSV Ch 6 Deployment
Deployment environment
Build a virtual machine image with installed default dependencies and allow it to check out code and deploy service to reduce default dependency setup time.
To avoid dev checking into a single server and change the code only in there and cause inconsistency , we can make the server immutable.
Sometimes the time and cost to reproduce production-like environments can be prohibitive, so you have to make compromises.
MSV Ch 6 Deployment
Continuous Integration
Continuous Integration: the continuous assembling and testing of our entire complex and rapidly evolving ecosystem.
the fundamental goal of CI is to automatically catch problematic changes as early as possible.
the earlier a bug is captured, the lower cost to fix that.
SWG Ch 23 Continuous Integration
Continuous delivery
Faster is safer: Ship early and often and in small batches to reduce the risk of each release and to minimize time to market.
At scale, increased complexity usually manifests as increased release latency. Frequent release trains allow for minimal divergence from a known good position, with the recency of changes aiding in resolving issues.
Meet Your Release Deadline: you can’t delay a release to include your new feature. you can only ride onto the next release train
Evaluate changes in isolation: Flag guard any features to be able to isolate problems early.
SWG Ch 24 continuous delivery
How to reduce the risk of large deployment scope
The larger the scope of a deployment and the higher the risk of a release, the more likely we are to break something. A key driver to ensuring we can release our software frequently is based on the idea that we release small changes as soon as they are ready
MSV Ch 7 Testing
Related Chapters
SAP ch 5 Deployability
MSV Ch 6 Deployment
SWG Ch 16 version controls and branch management
SWG Ch 17 code search
SWG Ch 18 build system
SWG Ch 19 code review tool
SWG Ch 20 static analysis
SWG ch 22 large scale changes
SWG Ch 23 Continuous Integration
SWG Ch 24 continuous delivery
