Ever wonder how a big site like Stack Overflow handles code deployment?

We’ve talked about Stack Overflow’s architecture and the hardware behind it. The next most requested topic was Deployment. How do we get code a developer (or some random stranger) writes into production? Let’s break it down. Keep in mind that we’re talking about deploying Stack Overflow for the example, but most of our projects follow almost an identical pattern to deploy a website or a service.

Source: Nick Craver – Stack Overflow: How We Do Deployment – 2016 Edition

Fascinating look into how Stack Overflow code gets from a developers workstation to production servers. There are many good ideas about development workflow in here.

GitHub adds commit squashing to tidy up your commit history

Commit squashing has the benefit of keeping your git history tidy and easier to digest than the alternative created by merge commits. While merge commits retain commits like “oops missed a spot” and “maybe fix that test? [round 2]”, squashing retains the changes but omits the individual commits from history. Many people prefer this workflow because, while those work-in-progress commits are helpful when working on a feature branch, they aren’t necessarily important to retain when looking at the history of your base branch.

Squash your commits – GitHub

New feature allows for cleaner commits in your code and more suitable for a broader range of workflows.

So you want Git, Docker, and continuous integration for your documents?

The power of GitDocker, and continuous integration (CI) can be leveraged to makeTeX document compilation easy while keeping track of different variants and versions. On the top of these technologies, a flexible workflow can be developed to reflect successive changes in TeX documents in each PDF—versioned with a progressive number, document-v4.pdf, say. 

Git, Docker, and continuous integration for TeX documents | Opensource.com https://opensource.com/business/15/12/git-docker-continuous-integration-tex-documents?sc_cid=701600000011kEYAAY

This makes me think about every time I hear someone say all we need for legislation/court documents/legal documents is Github. The workflow described in this article would indeed solve any number of document issues, but I can’t imagine in my world really using this.

Apache NiFi supports powerful and scalable directed graphs of data routing, transformation, and system mediation logic.

Put simply NiFi was built to automate the flow of data between systems. While the term dataflow is used in a variety of contexts, we’ll use it here to mean the automated and managed flow of information between systems. This problem space has been around ever since enterprises had more than one system, where some of the systems created data and some of the systems consumed data. The problems and solution patterns that emerged have been discussed and articulated extensively. A comprehensive and readily consumed form is found in the Enterprise Integration Patterns [eip].

Source: Apache NiFi Documentation

This looks interesting. I wonder if it can be used to handle the flow of information on the CALI systems?

Gerrit is a web-based code review tool built on top of the git version control system

Gerrit is intended to provide a light weight framework for reviewing every commit before it is accepted into the code base. Changes are uploaded to Gerrit but don’t actually become a part of the project until they’ve been reviewed and accepted. In many ways this is simply tooling to support the standard open source process of submitting patches which are then reviewed by the project members before being applied to the code base. However Gerrit goes a step further making it simple for all committers on a project to ensure that changes are checked over before they’re actually applied. Because of this Gerrit is equally useful where all users are trusted committers such as may be the case with closed-source commercial development. Either way it’s still desirable to have code reviewed to improve the quality and maintainability of the code. After all, if only one person has seen the code it may be a little difficult to maintain when that person leaves.

via Gerrit Code Review – A Quick Introduction.

This is like something that may be worth doing to help make sure at least one other person is looking over code before it gets committed. Deploying code that only one of us has ever seen is a bit of a problem around here especially when it fails.