doc: update with review part

Signed-off-by: Marc Mattmüller <marc.mattmueller@netmodule.com>
This commit is contained in:
Marc Mattmüller 2023-09-18 16:52:00 +02:00
parent 32370ec4be
commit 8942501294
2 changed files with 82 additions and 0 deletions

View File

@ -3,6 +3,8 @@
You can adapt this file completely to your liking, but it should at least
contain the root `toctree` directive.
.. _docEntryPoint:
Welcome to NetModule Wireless Linux CI/CD's documentation!
==========================================================

View File

@ -0,0 +1,80 @@
##############
NWL CI Review
##############
Foreword
##############
There is a big difference if you set up a CI/CD environment for a life cycle- or for a development workflow. The CI part
grow with the development and must be very flexible and easily adaptable. Thus such a CI cannot be that static as a
CI/CD environment for a life cycle product. From this point of view there is a big difference between the CI/CD setups
at HAC and Netmodule. At Netmodule the CI is part of the work to develop and/or release a software and shall as well be
adaptable in absence (due to vacation or similar) of the responsible for the CI.
With the integration of Netmodule into Belden there is another part which crossed an efficient work concerning CI: the
IT infrastructure.
Connections to productive systems were not possible, are no longer foreseen, different active directories, only one ...
Additionally, the NWL CI acts as proof of concept in several ways and of course for any other product basing on the
CoreOS. Thus, the following part and the sphinx documentation gives more insights.
Overview
#########
There are currently two instances available:
* the HAC way
* using Ansible playbooks
For both instances servers set up by the Guardians are used, see the following IPs:
* 10.115.101.98 = NWL CI the HAC way
* 10.115.101.101 = NWL CI using ansible
* 10.115.101.100 = supporting server, like webserver for sstate-cache mirror, etc.
You will find the entry point in of the documentation here: :ref:`docEntryPoint`.
Setup the HAC way
******************
This setup uses the repositories `build-docker <https://bitbucket.gad.local/projects/INET-CI/repos/build-docker/browse>`_
and `build-admin <https://bitbucket.gad.local/projects/INET-CI/repos/build-admin/browse>`_. The adaptions for NWL are
reflected in a branch (branch name = *feature/ci/nwl*) of *build-docker*. The build server has the repository
*build-admin* cloned and holds the necessary changes and configurations locally.
The HAC way integrates the seeding of the build-pipeline, the used credentials and plugins directly into the docker
image. A script residing in build-admin creates and starts the instance by mounting secrets, known hosts file, etc.
.. note::
There are a lot of manually performed steps necessary to bring up such an instance.
Setup using Ansible Playbook
*****************************
This setup acts as proof of concept using Ansible and JCasC (Jenkins Configuration as Code) to setup a complete CI
instance, i.e. there is code in a git repository describing how the instance is set up. The entire instance is described
in two yaml files. To bring it up manually, one has to clone the CI repository, prepare the secret directory and start
the instance using docker-compose.
The functionality is the same as in the HAC way but finally the setup can **be done nearly by button press**.
Maintaining is well possible by button press once the Ansible playbook is created. Another difference is, that one can
tag the Jenkins infrastructure.
Next Steps / Open Points
*************************
Active directory integration where both company collaborators are in, i.e. Belden and Netmodule. With this it would be
possible to add the LDAP connection and have a proper setup where each developer is able to login with its credentials.
.. note::
Currently Netmodule is not yet integrated in the Belden AD. Thus at a LDAP connection does not resolve this login
topic.
As there are a lot of manual steps necessary in the HAC way of creating instances, the focus resides on the instance
using Ansible playbooks. Such an approach with playbooks relieves the Guardian team as things can be performed with
button press (once set up).
In the ansible instance the entire part of software tests on devices (like e.g. robot framework tests, LAVA tests, etc.)
are not yet integrated.
Any further steps depend on how the workflow and release process will be defined.