Agile projects require agile methods – “software nerds” love automation
When it comes to automation, some sceptics are quick to point out the disadvantage that flexibility and adaptability suffer as the degree of automation increases. While this argument may apply to logistical systems as such, with some reservations, it is by no means true in the context of agile software development. On the contrary: agile projects and individual customer instances of a software application demand automation in order to enable the efficient merging of different source code parts (branches). This means that the code base can always be kept up to date and delivered at short notice. The first principle of the “Agile Manifesto” states: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” [Quelle: http://agilemanifesto.org/iso/de/principles.html]
Regardless of the Agile Manifesto, it is well known that increasing agility in software development inevitably increases the distribution times referred to in process planning. Small packages (sprints) should be developed (build), tested (test) and finally provided (deployed) in short cycles. The smaller the packages are, the greater the effort required in addition to the actual source code development in favor of agility in the overall project. The challenge of individual customer instances for a software solution increases the additional effort. Each individual instance must be kept release-capable or always restored to the current code base and the individual configuration settings must be specifically tested with each change.
The typical development process for new functions begins with a specification of the requirements by a product manager. These are then broken down into smaller task packages and processed by the software developers. Once the programming is complete, the code first undergoes a series of static tests and quality assurance analyses. The software, with the new function added, is then rolled out on a test system and subjected to a large number of functional tests. These tests ensure that the implementation meets the initially defined requirements and works without errors. In addition, it is checked whether all existing functionalities are still available without any problems.
Once the tests have been successfully completed and approved by the responsible product manager and/or the customer, the new source code is integrated into the current release-ready code base (merge). Depending on the customer’s requirements, the new functions can now be rolled out to the respective production system either immediately or at a later date as part of a larger function update. The duration from specification to successful roll-out can range from a few minutes to several weeks, depending on the scope.
It is clear that the tests for quality assurance are essential but at the same time, if carried out manually, are time-consuming and therefore cost-intensive. It therefore makes sense to bundle features and release them in larger batches in order to minimize the necessary testing effort. However, this contradicts the aforementioned goal of providing our customers with updates and features early and continuously. At the same time, this approach increases the complexity of the updates, which may lead to additional time being spent on merging and integrating the individual code components, known as “integration hell”.
In order to close this gap and escape the hell of code integration, LOGSOL GmbH will rely on the Continuous Integration (CI), Continuous Delivery (CD) and Continuous Deployment (CD) methods in future. These complement the agile mindset and DevOps culture already established at LOGSOL. Perhaps they can be combined even better in the future (see illustration).
Continuous Integration (CI) represents the first stage, which initially requires a fundamental change in the software development workflow. The aim is to no longer collectively test and merge software adaptations in future, but to do so immediately and as frequently as possible – ideally several times a day. With manual quality control, this would generate an immense amount of work, which could exceed the actual development effort many times over. The solution here is increased standardization and automation along the entire workflow, the so-called CI pipeline. This pipeline includes tools and functions that are automatically triggered each time new code is added and a fully automated quality check of the current software status is performed. In addition to static checks for conformity with the guidelines for secure software development, this also includes so-called automatic user acceptance tests (UAT). This automates the validation of whether the software continues to meet customer and user requirements and is fully functional. For this purpose, not only the components affected by the adaptation are tested, but also the entire software including all existing functions. The degree of test automation rarely exceeds 75%, but should cover the 20% of the software that is essential for the function. Due to the high frequency of test executions in the CI pipeline concept, the break-even point between the effort required to create UATs and the benefits is quickly reached. For the implementation of the UATs, all possible use cases were defined by the responsible product managers and project managers (including negative tests). The test team then implemented the UATs in such a way that each test is executed fully automatically directly in the software and compared with the expected result. Ideally, these tests are defined and created before the actual programming begins so that software developers can validate their solution against the specification from the very first line of code. This reduces the effort required to actually test the software to a minimum. In return, however, there is a one-off initial outlay for creating, expanding or adapting the automatic user acceptance tests. In future, however, it will be possible to guarantee that every adaptation has been subjected to a standardized test process and that the software works perfectly.
At the end of the CI workflow or CI pipeline, there is a software version that can be packaged, configured and rolled out to a production or test system by an employee at any time. In this context, the Continuous Delivery (CD) concept goes one step further and represents the next stage of planned automation at LOGSOL. Here, the CI workflow must be expanded to include the necessary steps to prepare the software so that it can be rolled out at any time without further manual intervention. At the end of the pipeline, the software is automatically provided together with all the necessary components in a so-called repository. From here, it can be deployed to a production system at the touch of a button, for example by a product manager and project manager. This means that the decision as to when and where which function is released into a live system is the responsibility of the relevant product managers in close coordination with the customer.
Continuous Deployment, as the final expansion stage, provides all tools in such a way that the final step, i.e. deployment to the production system, is also fully automated. This makes it possible for new functions and adaptations to be available on the customer’s production system just minutes after the new code has been checked in, without the need for manual intervention and intermediate steps by software developers or product managers. At the same time, good and complete test coverage within the CI/CD pipeline ensures that the specified requirements have been met and that the existing components continue to function as desired. Thanks to the LOGSOL development department, the technical basis for the pipeline will be ready by the turn of the year 2020-2021. However, the new approach already needs to be established culturally and the automated tests need to be continuously maintained and updated.
The described automation of integration, delivery and deployment processes in software development in favor of agility in customer projects acts as a catalyst for test automation. However, the balancing act of deciding what or how much to test and the associated effort/risk remains exciting in any case and cannot (yet) be automated – we’ll stay tuned!