Hands-On Docker for Microservices with Python

上QQ阅读APP看书，第一时间看更新

Producing automated builds

The core element in CI is generating automated builds integrated with a source control system. A software build is a process that (starting from the source code) performs a series of actions and produces an output. If the project is written in a compiled language, the output will typically be the compiled program.

If we want to have quality software, then part of the build involves checking that the produced code follows code standards. If the code doesn't follow those standards, then the build will return an error.

A common way of describing errors on a build is to say that the build is broken. A build can break in different ways, and some kinds of error may stop it early (such as a compilation error before running tests) or we can continue to detect further issues (such as running all tests to return all possible errors).

Some examples of steps that can be a part of the build are as follows:

Compiling the code.

Python usually doesn't need to be compiled, but it might be required if you use C extensions (modules written in C and imported from Python: https://docs.python.org/3/extending/) or tools such as Cython ( https://cython.org/ ).

Running unit tests
Running static code analysis tools
Building one or more containers
Checking dependencies for known vulnerabilities with a tool such as Safety (https://pyup.io/safety/)
Generating a binary or source package for distribution. For example, RPM (https://rpm.org/), Debian packages (https://www.debian.org/doc/manuals/debian-faq/ch-pkg_basics), and so on
Running other kinds of tests
Generating reports, diagrams, or other assets from the code

Anything that can run automatically can be a part of a build. A local build can be generated at any time, even with code that's still in progress. This is important for debugging and solving issues. But automated builds will run against each individual commit, and not at any intermediate stage. This makes it very explicit to check what code is expected to run in production and what code is still work in progress.

Note that a single commit may still be work in progress, but it will be worth committing anyway. Maybe it's a single step toward a feature, more than one person is working on the same part of the code, or it's work spread over several days and the code gets pushed at the end of the day. No matter, each commit is a reproducible step that can be built and checked whether the build is successful or not.

Running the build for each commit detects problems very quickly. If commits are small, a breaking change is easy to pinpoint. It also makes it easy to revert changes that break the build and go back to known working code.