doc: added CI use-cases

visualized the different use-cases for the CI environment
including the TDD workflow.

Signed-off-by: Marc Mattmüller <marc.mattmueller@netmodule.com>

doc/src/nextlevel-ci/ciUseCases.rst

@@ -0,0 +1,102 @@
+.. _ciUseCases:
+
+********************************
+CI Use-Cases and Recommendations
+********************************
+Introduction
+############
+There was a request to visualize workflows of different use-cases depending on the working items at Belden/HAC/NM. This
+request was as well forced due to my recommendation to develop test driven. But first of all we look at some locations
+for development:
+
+*  the core of the operating system (kernel space)
+*  the user space level with well defined API
+
+Even if I still think that test driven development in the kernel space is beneficial, I focus on two categories:
+
+*  development of the operating system Linux using Yocto
+
+    -  most parts of the CoreOS
+    -  some parts of BIL and/or NWL
+
+*  development of applications running in the user space of Linux (all applications having a well defined Hardware
+   abstraction layer like the Linux API or POSIX)
+
+    -  I guess the bigger part of the features of the Belden/HAC/NM products
+
+**As a matter of course it depends on the build environment you want to use.** Yocto is a powerful build framework and
+provides the functionality to build the complete software image package with operating system and all its user space
+applications and/or the operation system only. But it provides as well of a software development kit including a
+toolchain and rootfs.
+
+This means as a user space application developer **you do not have to launch Yocto** to build your application. Why am I
+pointing that out. In software development you want to speed-up your development and preferably you do not want to
+switch your IDE to build the application. Thus you may want a toolchain and rootfs installed on your local development
+environment and develop your application without waiting too long for feedback on your changes, right?
+
+That's why the CI environment differs for these different use-cases.
+
+
+CI using Yocto
+##############
+The selected build framework is Yocto which is well known at NetModule's due to their OEM Linux. Yocto was decided to be
+used for CoreOS, BIL (Belden Industrial Linux) and NWL (Netmodule Wireless Linux). Hence a proposed CI chain looks like
+this:
+
+|ciYoctoBased|
+
+The regression tests need to be as elaborated to not break the defined features provided by CoreOS, BIL or NWL. This is
+not only a test to see whether the operating system is booting into the newly created version or not. There are a lot of
+services that need to start successfully to fulfill the defined features for CoreOS, BIL and/or NWL. To understand this
+better let's have a look at the boot scenario that the operating system itself is booting but a specific services like
+network manager crashes at start-up. This would be an unwanted behaviour. If we would just cover the boot-up and not the
+essential funtion, a pull/merge request verification makes no sense here.
+
+The extended test block was introduced to trigger more elaborated tests on request and to not prolong a pull/merge
+request. This extended tests I would trigger as the asynchronuous ones known at HAC.
+
+
+CI Creating a Release Package or Complete Software Package
+##########################################################
+.. note::
+    There are different possibilities/mechanisms to build a release- or complete software package.
+
+The following recommendation uses Yocto to build a release- and/or a complete software package for a product.
+
+|ciSwPkg|
+
+This chain is pretty similar to the one in the previous section except that there are additional blocks like tagging and
+deploying to ROW (rest of world).
+
+
+CI User-Space Application
+#########################
+As mentioned in the `Introduction`_ a CI using Yocto for a user-space application may take too long for a feedback.
+Additionally with unit tests you may introduce very dedicated tests which are in real environments hardly achievable. In
+a year 2023 it is unimaginable to not develop test driven. Hence I added the workflow again here:
+
+|userSpaceAppDev|
+
+
+After having the feature fully implemented, the developer commits the code to the feature branch and creates a
+pull/merge request. This triggers the CI environment based on the units tests of the application as shown below. If you
+want to enhance your CI for this application you may deploy the binary to a target and launch tests on the target.
+
+|ciUserSpaceApp|
+
+
+Gitlab and as well Bitbucket are able to launch CI pipelines for a repository. I recommend to use such pipelines for the
+application CI.
+
+If it comes to a software package for a product where multiple applications like the example above are included, the CI
+chaine as descibes in `CI Creating a Release Package or Complete Software Package`_ is recommended.
+
+
+.. |ciYoctoBased|      image:: ./media/ci-yocto-based.png
+                         :width: 800px
+.. |ciSwPkg|           image:: ./media/ci-completePkg-Releasing.png
+                         :width: 800px
+.. |ciUserSpaceApp|    image:: ./media/ci-userspace-app.png
+                         :width: 800px
+.. |userSpaceAppDev|   image:: ./media/userspace-app-development.png
+                         :width: 800px