doc: update with review part
Signed-off-by: Marc Mattmüller <marc.mattmueller@netmodule.com>
This commit is contained in:
parent
32370ec4be
commit
8942501294
|
|
@ -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!
|
||||
==========================================================
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
Loading…
Reference in New Issue