How do you document units, modules, libraries, and APIs in your system, so that people know how to use them?
Note that for the purposes of this discussion we are not referring to code comments, which are mainly directed
at the team constructing and maintaining the module, but rather to client documentation for those who will use it.
This is the last part in our series on designing CI/CD pipelines. The first part of the series
defined the objectives of the pipelines, and defined the stages that go with them. The second part
covered in detail the core Build-Deploy-Test scripts, which together effectively implement all the
necessary functionality. In this third and final part, we will cover how we put together all of the
stages described in Part 1, by composing them using the blocks described in Part 2.
We will also cover a…
The first part of the series defined the objectives of the pipelines, and defined the stages
that go with them. In this second part, I will focus on the core Build-Deploy-Test loop, which forms
the core of each pipeline, and the design objectives and design decisions we made. If you have not read
Part 1, I would recommend that you do so first, since this part will assume some context that
is provided in the previous article.