to be performed at once when they are occurring (e.g. the outage of a server). In Scrum, activities need to be planned. This is not possible with these kinds of tasks. Kanban makes it possible to immediately work on high priority targets and to include feature development. Every DevOps team has the right to start and stop instances and services in their respective stage, which allows controlled self-services on cloud resources (O3+O5).
With this arrangement, the next step is to set up a continuous deployment process (T4). In this case, automation is the key for quality and efficiency with techniques like infrastructure as code [LM12] being the key factors. EB is successfully working with AWS CloudFormation [DP15] to have the infrastructure as code, which makes the configuration reproducible (O4). Code can be deployed directly to test instances from the build server (T4). Only the release needs manual interaction.
Software reuse with inner source
One key decision to enable software reuse (T3) is the adaption of open source techniques into our development processes. Here, EB follows the inner source (IS) approach [CR15] by establishing a software forge where the source code was made available to all developers. A forge is a central place where a well-documented code base is kept forever with the possibility to search [CR15]. This allows all developers to use and review the code. Following Linus´s law “Given enough eyeballs, all bugs are shallow” [RE01] a higher code quality can be achieved (T5) than with the common four-eye principle alone. Experience showed that the code quality improved and that teams were starting to work together, especially on common tooling. A set of microservices is available via the forge, enabling software reuse in other projects and improving the overall development time.
With the current setup, EB has begun to improve and create new environments by changing the culture in software development from a classic agile setup to a