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

Popular posts from this blog

Does Free Consciousness exist ？

-
Image
I see a study:  Discovery of quantum vibrations in ‘microtubules’ inside brain neurons supports controversial theory of consciousness  shared on social media. Some one comments that this study indicates that human have free consciouness and the freedom comes from quantum process. I disagree with this comments. To oppose this comment clearly, I will raise and answer two questions. First, what does ‘microtubules’ do inside neurons ? Second what is free consciousness ? What does ‘microtubules’ do inside neurons ? The above picture is from Wikipedia. It shows the structure of a neuron and what ‘microtubules’ is in neuron. The way how neuron works is: A neuron collect chemical signals from many other neurons and generate a signal in the left side of the above picture and send the signal to the right side the above picture through the ‘microtubules’ and finally convert that signal to chemical material and emit them. So ‘microtubules’ is more like a cable to transmit signals. And i
Read more

View and Build Government Organization like a Software

-
  Background Recently I read several books on software architecture. I also read some books about politics and government such as The Logic of Governance in China (Zhou, Xueguang)  and America against America (Wang, Huning). I feel software and government do have many similarities. For example, both of them are created to execute tasks based on some stable business logic,  to satisfy human needs, to serve a large user base, have a topological structure etc. Software system is more like a simplified version of government organizations. In science, a theory is usually created by studying some simple model with a lot of  assumptions and then applied to a more complicated context. I’m thinking maybe we can do the same thing from software architecture to government organization.  The goal of this article is to inspire people on different ways of building government organizations based on software development principles and test them in practice. This is more of a collection of my own thoug
Read more

Software Architecture Books Summary And Highlights -- Part 1 Goal, Introduction And Index

-
  Goal And Target Audience This is a summary and highlights of 6 software engineering and architecture related books I recently read. All the 6 books are very heavy and interesting. Reading real contents of them is always recommended. The target audience is experienced software engineers who want to learn more in larger system design and architecture. The goal of this article is to provide summaries of the 6 books as well as brief highlights of interesting or important contents from the 6 books so that the target audience could learn the 6 books’ important ideas quickly and read only important chapters and save time. The highlights and summaries will be divided into several general categories. Each category contains a highlight section and a related chapters section. The related chapters section contains all chapter references which are related to the category’s topic. The highlight section contains a brief summary of interesting or important or enlightening contents from the relat
Read more