diff --git a/doc/src/index.rst b/doc/src/index.rst index 8d4aa9a..2e55614 100644 --- a/doc/src/index.rst +++ b/doc/src/index.rst @@ -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! ========================================================== diff --git a/doc/src/setup/nwl-ci-review.rst b/doc/src/setup/nwl-ci-review.rst new file mode 100644 index 0000000..5eaa7b5 --- /dev/null +++ b/doc/src/setup/nwl-ci-review.rst @@ -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 `_ +and `build-admin `_. 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.