Software development

Abstract

This section sketches a prototype workflow for software development.

Suggested workflow for software development

First of all a developer needs access to a development workstation. Either he can use one of the existing development workstations, or a new one can be created. However, in all cases the development workstation components need to be registered in the SL. Then a system administrator can easily set up (or recreate) a given version of that workstation. This document describes in detail how this can be done.

Now the developer can log in on his development workstation. He retrieves the version he needs to work on from CVS, which is a part of our SL too. He will make the neccessary modifications and additions and store the alterations in CVS.

Other developers may work on the code too and/or create new code. Eventually, the new (pre)version is transferred to a well defined test station - again: all its components are registered in the SL too. Here the software is compiled and tests are performed. If the technical- and automated tests succeed, a formal prerelease is issued by the Release Manager. And of course the (compiled) pre-release is also stored in the SL.

Now the prerelease is transferred to a well defined acceptance environment. In practice this is the very same environment used to test the software, but without the testing software and also configured to match the final production environment as close as possible.

When the acceptance tests were succesful, the Release Manager formally issues a Release. The release is stored in the SL.

The SL also contains the definition of the test- and developmentstations, including the list of all hardware components. In theory it is possible to reproduce the entire trajectory, from the commit of the first lines of code to the final product, since all necessary data is stored in the. SL. For example, to reproduce a test, you "just" have to grab the proper type of hardware from a shelf, install the proper operating system and packages, retrieve the proper prerelease of the software and run the tests once more.

This requires at least:

  • setting up a SL

  • enabling swift recreation of environments from that SL

This document describes what tools and procedures to use to enable swift recreation of a (version of a) Linux workstation. It also defines the items that need to be stored in the SL to enable the reconstruction. However, it does not detail the exact structure of the DSL, please consult The Definitive Software Library for details.