Beginner

An artifact is the output derived from your build process.

Sadly, artifacts are often built whenever they’re needed. A lot of the builds just build that which has been built before.

Even though this could be about contributing to avoiding the environmental crisis, it is also justifiable to save and manage artifacts simply to save wait-states and bottlenecks in the software development process.

Stop building things that haven’t changed and start reusing colleagues’ artifacts - install an artifact management system.

In a functional test, you test the features that the system offers as a whole, seen from the end user’s perspective.

In the previous millennium such a test would be planned by a person with domain knowledge, then executed prior to every release by testers performing manual operations based on written instructions.

A more contemporary strategy is to have the person with domain knowledge manage a team of developers, who are actually implementing the tests as code, and then give the software developers access to execute these test in their production-like environments.

The release train branching strategy is similar to what is sometimes referred to as late branching or trunk based development. Essentially it implies that in your entire branch tree there is only one branch that is meant to be long-lived.

Consequently, there is only one way you can contribute to a product and have your code released, and that is to deliver your code to the mainline.

In a release train strategy, the mainline is on it’s way to production all the time, and therefore anything that isn’t meant for production as soon as possible, shouldn’t be delivered to the mainline.

Whether or not a particular code snippet gets tested is often a matter of how easy it is to test.

Organize your code in easily accessible features. Make each feature available through one interface only.

Since the feature is only available through one interface, it’s safe to consider it tested, when you have massaged it.

At the end of the day, more code gets tested.

The ability of a release to be deployed is such an essential part of the delivery that the developer is expected to take full responsibility for this process.

The deployment should be automated because it’s a task that needs to be carried out often and is not necessarily trivial.

You want your deployment as code.

Initiatives, new tools and approaches are often of natural interest to developers and they might experiment and research without explicitly being told to do so.

But Continuous Delivery is a paradigm that strives to build quality into the product rather than gluing it on afterwards.

Transitioning is going to take time. It needs planning. It needs prioritization. It needs funding. You need a road map. Continuous Delivery is not a quilted patchwork. Be sure to make it a corporate thing, not just a neat idea.