Clearly, the shortening of the path between development and production by using CI/CD is a key part, as is the iterative- and business-focused nature of agile methods. It also means changing the type of work that people do. Software developers should play an active role in looking after production systems rather than just creating new functions. The operations staff should focus on ways to automate monotonous tasks so that they can move on to higher value activities, such as creating more autonomically self-healing environments. This particular role change is often referred to as a Site Reliability Engineer to highlight the fact that they too are software engineers. 

In the perfect DevOps world, there would be only a single team consisting of DevOps engineers. Few organizations reach anything close to that point, but many gain significant benefit by keeping a focus on reducing the gap between the teams and introducing system reliability engineer roles. 

## 4.3 Twelve-factor apps 

The idea of a 12-factor app  is associated with the concepts of cloud-native, containerization, and microservices architecture. The 12 factors pre-date the mainstream use of container technology and microservices. That context is important because it means that we should see the 12 factors for what they are: A well-written and long-lived set of guidelines for implementing decoupled, scalable, and maintainable application components, but not as a definitive list for containerization, microservices or cloud-native concepts. 

With that caveat in mind, in this section we provide: 

GLYPH<SM590000> A brief summary of the 12 factors because they overlaps with many of the elements of cloud-native. 

GLYPH<SM590000> Bring the 12 factors up to date by relating them to current technologies that are described in this book, such as APIs and containerization. 

GLYPH<SM590000> Show how tightly the 12 factors are interrelated to demonstrate how important it is to commit to a significant change in approach if you are to gain the benefits of the 12 factors. 

## Factor 1 - Codebase: One codebase tracked in revision control with many deployments 

A codebase  is defined as a collection of code that is used to build an application. To encapsulate the application, the codebase should be stored in only one version control repository, such as Git. 

Although it is sometimes necessary to share code between applications, each application should have its own codebase. Break the shared code into a separate repository that multiple applications can share. This shared code can then be imported as a versioned library dependency, as described in “ Factor 2 - Dependencies: Explicitly declare and isolate dependencies ”). 

The codebase should be the same even when deployed to different environments, as described in “ Factor 3 - Configuration data: Store environment-specific configurations in environment variables ” on page 101). 

