Build

Yes. But it doesn't build on THAT machine.

When code changes are committed to the repository, your CI server kicks in automatically and starts a build.

It might not even be an actual build, it can be any kind of automated action that is part of a verification process implied in the project’s “definition of done”.

If a build step fails, the developer is notified directly so he can start working on fixing the issue immediately. The shorter the feedback loop, the better.

Are you building that over and over and over again?

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.

If it's boring - automate it. Release notes are boring.

Whenever you ship a new release you probably need a release note, a report listing the new version number, fixed issues, new features…

Why write all that manually? By building up your traces and recording your trails as you work, you can pull all this information out of your backend automatically.

You’ve written your last release note. From here on out it’s release notes as code.

Run a tight ship - control software from cradle to grave

Take an arbitrary piece of hardware; As part of the Product Lifecycle Management the manufacturer has a complete trace to the individual versions of all the components that went into it.

Application Lifecycle Management means that you apply the same approach to software. You trace everything.

The requirements that created the tasks, the commits that resolved them, the compiler that built them, the tests you ran, the environment you ran them in, the test results and so on. When the software reaches production, you know the specifics of everything that created it.

A full ride produces a release candidate

Split up your builds and verifications into a pipeline consisting of multiple stages. Use this approach to keep your builds as fast as possible, your feedback loop as short as possible and your developers notified as quickly as possible despite having long-running builds.

In your pipeline, each step provides more confidence in your code than the previous one.