Add Distro factory guide for DevOps' process automation (#411)

- Adds `architect-lifecycle` as Phase 1 prior to `distro-factory` in guides for a DevOps toolchain. 
- Adds Figure 1 overview.
- Adds architect-lifecycle to toctree in maintenance.rst

Signed-off-by: Michael Vincerra <michael.vincerra@intel.com>

Incorporate @mbelluzzo feedback. In progress.
Include reference/reference changes.

Signed-off-by: Michael Vincerra <michael.vincerra@intel.com>

* Redefine scope, title of document: Maintain CL life-cycle.

Signed-off-by: Michael Vincerra <michael.vincerra@intel.com>

* Revise intro after re-scoping.

Signed-off-by: Michael Vincerra <michael.vincerra@intel.com>

* Revises scope as overview of life-cycle; context for distro-factory.
Adds new simplified graphic.

Signed-off-by: Michael Vincerra <michael.vincerra@intel.com>

* Retitles; revises intro and Content Workflow.
Revise Figure 1 and renames it. Revises document filename.

Signed-off-by: Michael Vincerra <michael.vincerra@intel.com>

* Removes older version.

Signed-off-by: Michael Vincerra <michael.vincerra@intel.com>

* Adds revised title to toctree. Corrects missing `-`.

Signed-off-by: Michael Vincerra <michael.vincerra@intel.com>

source/clear-linux/concepts/swupd-about.rst

@@ -57,7 +57,6 @@ multiple compression formats, allowing :command:`swupd` to utilize the most
 efficiently compressed format for a |CL| system to minimize the cost
 to update.
 
-
 Update integrity
 ----------------
 
@@ -98,5 +97,5 @@ For more information on bundles, visit:
 
 .. [1] The software update technology for |CL-ATTR| was first presented at the Linux Plumbers conference in 2012.
 
-.. _Stateless: https://clearlinux.org/features/stateless
 .. _swupd man page: https://github.com/clearlinux/swupd-client/blob/master/docs/swupd.1.rst
+

source/clear-linux/guides/maintenance/architect-lifecycle.rst

@@ -0,0 +1,79 @@
+.. architect-lifecycle:
+
+Architect the life-cycle of |CL-ATTR|
+#####################################
+
+This guide provides DevOps with a model to architect the life-cycle of a |CL|
+derivative that integrates custom software and content using distinct
+workflows.
+
+Maintaining a |CL| derivative requires:
+
+* Monitoring upstream |CL| for new releases
+* Building software packages and staging
+* Employing CI/CD automation for building releases
+* Integrating Quality Assurance for testing and validation
+
+This guide provides the foundation of the recommended infrastructure.
+
+How it works
+************
+
+.. contents::
+   :local:
+   :depth: 1
+
+Prerequisites
+*************
+
+* A repository with software RPM artifacts and a CI/CD system with a |CL|
+  machine for building `mixes`
+
+* Experience using :ref:`mixer <mixer>` to create a |CL|-based distro
+
+* Experience using :ref:`swupd <swupd-guide>` for maintaining the |CL|
+  build environment
+
+* Familiarity with |CL| architecture and reuse of its content in releases
+
+Description
+***********
+
+Coordinated infrastructure can be deployed to automate the life-cycle
+of your |CL| derivative. We divide deployment of this infrastucture in two
+parts: *Content Workflow*; and *Release Workflow*, shown in Figure 1. Distro Factory manages the *Release Workflow* while capturing the requirements for
+maintaining a long-term release cadence.
+
+.. figure:: figures/architect-lifecycle-1.png
+   :scale: 100%
+   :alt: |CL| maintenance life-cycle
+
+   Figure 1: |CL| maintenance life-cycle
+
+Content workflow
+****************
+
+The *Content Workflow* (Figure 1) orchestrates the processes used to manage
+the creation of content for the distribution. This includes everything from detecting a new release in a custom software repository to generating RPM package files. The RPM files serve as intermediary artifacts that track software dependencies and provide file-level data consumed in a *Release Workflow*.  The `Watcher Pipeline`_ checks |CL| and a content provider, such as Koji, to determine if a new release is necessary.
+
+Release workflow
+****************
+
+The *Release Workflow* (Figure 1) gathers the content of the RPMs and
+ensures it can be consumed by :ref:`mixer <mixer>`. A content web server
+hosts the |CL| derivative, to which targets connect for updating their OSes.
+As an integral part of this toolchain, the *Release Pipeline* enables these
+derivatives to incorporate |CL| content into their own custom
+content. The *Watcher Pipeline* triggers the `Release Pipeline`_ to create
+new releases.
+
+Implementation
+**************
+
+Distro factory implements the *Release workflow*. To get started on a full implementation, visit |CL| `Distro factory documentation`_.
+
+.. _Distro factory documentation: https://github.com/clearlinux/clr-distro-factory/wiki#clear-linux-distro-factory
+
+.. _Release Pipeline: https://github.com/clearlinux/clr-distro-factory/wiki/Release
+
+.. _Watcher Pipeline: https://github.com/clearlinux/clr-distro-factory/wiki/Watcher

source/clear-linux/guides/maintenance/maintenance.rst

@@ -20,6 +20,7 @@ completed.
    kernel-modules
    mixer
    mixin
+   architect-lifecycle
    validate-signatures
    time
    hostname

source/clear-linux/reference/reference.rst

@@ -18,3 +18,4 @@ features.
    compatible-kernels
    system-requirements
    image-types
+   openssh-server