Deployment: Significance of Branching for Continuous Delivery

The deployment of software in DevOps is based on Continuous Delivery. Continuous Delivery enables all kinds of changes, including new features, configuration changes, bug fixes and experiments, to be put into production safely and quickly in a sustainable manner. A Branching strategy and Base Truncs play an important role in this.

Modern digital zettelkasten don't force the same sort of digital internal branching process that is described by Niklas Luhmann. Internal branching in these contexts is wholly reliant on the user to create it.

Many digital systems will create a concrete identifier to fix the idea within the system, but this runs the risk of ending up with a useless scrap heap.

Some modern systems provide the ability for one to add taxonomies like subject headings in a commonplace book tradition, which adds some level of linking. But if we take the fact that well interlinked cards are the most valuable in such a system then creating several links upfront may be a bit more work, but it provides more value in the long run.

Upfront links also don't require quite as much work at the card's initial creation as the creator already has the broader context of the idea. Creating links at a future date requires the reloading into their working memory of the card's idea and broader context.

Of course there may also be side benefits (including to memory) brought by the spaced repetition of the card's ideas as well as potential new contexts gained in the interim which may help add previously unconsidered links.

It can certainly be possible that at some level of linking, there is a law of diminishing returns the decreases the value of a card and its idea.

One of the benefits of physical card systems like Luhmann's is that the user is forced to add the card somewhere, thus making the first link of the idea into the system. Luhmann's system in particular creates a parent/sibling relation to other cards or starts a brand new branch.

Parag. K. V., Donnelly. C. A., (2020) Using information theory to optimise epidemic models for real-time prediction and estimation. PLOS. Retrieved from https://journals.plos.org/ploscompbiol/article?id=10.1371/journal.pcbi.1007990

Gleeson, J. P., Onaga, T., Fennell, P., Cotter, J., Burke, R., & O’Sullivan, D. J. P. (2020). Branching process descriptions of information cascades on Twitter. ArXiv:2007.08916 [Physics]. http://arxiv.org/abs/2007.08916

Endo, A., Centre for the Mathematical Modelling of Infectious Diseases COVID-19 Working Group, Abbott, S., Kucharski, A. J., & Funk, S. (2020). Estimating the overdispersion in COVID-19 transmission using outbreak sizes outside China. Wellcome Open Research, 5, 67. https://doi.org/10.12688/wellcomeopenres.15842.1

When the development of a feature takes a long time, it may be useful to continuously merge from develop into the feature branch. This has the following advantages:

• We can use the new features introduced in develop in the feature branch.
• We simplify the integration merge of the feature branch into develop that will happen at a later point.

Git gets this basic division of worlds right and is a fundamental departure from other version control systems like SVN. The feature that enables all this is nearly cost-free, instantaneous branching.

What makes this new world complex is not due to git, but instead because the world is, quite simply, complex! Good tools like git help us manage (some of) the complexity.

Good defaults are sometimes hard to recognize, especially when the tool is complex.

Questioning the defaults-- and deciding why you would keep them or change them-- is a good antidote to dismissing something due to not understanding it.

If you can't understand why you don't like the defaults, then decide what you would choose instead and why you would change the default as it stands. Does the default make it easy to do the "right" thing AND hard to do the "wrong" thing? The second part of that statement is the most important since it might not be obvious what the "right" thing is.

Even if you don't like the defaults, ask yourself if they continually lead you away from perils and problems that would plague you if a different set of defaults were chosen?