3.2.13 DevOps 3.2.14 Creating integrations is becoming easier 64  Accelerating Modernization with Agile Integration The good news is that the steps you have taken to make the run time more suited to  containers have also made both these tasks simpler. If you recall, installing and configuring  the integration run time is now a matter of file copy commands, as is the addition of the  integration artifacts. These artifacts can be programmed into easily understood build pipeline  scripts. These scripts can be triggered based on events from the source control, resulting in a  container image that is ready for deployment. Deployment is now something that based on  additional policy information, which K8s already has.  We are over-simplifying, but the point is that the complexities of creating CI/CD pipelines are  reduced after we take on the elements of the cloud-native approach.  An example of CI/CD pipelines for App Connect is shown in 7.5, “Continuous Integration and  Continuous Delivery Pipeline using IBM App Connect V11 architecture” on page 465. Last but not least, we come to people, or more specifically, how people collaborate across  teams and which teams they are in. To keep that close link between what we implement and  what the business sees and uses in production, we must narrow the gap between  development and operations.  You must get away from the “throw it over the wall” mentality that can occur between heavily  separated development and operations teams and give both sides an investment in each  other’s success.  This situation is DevOps .  The same potential separations exist in the integration space as they do in application  development, where DevOps was first introduced.  On a technical level, we can say that through image-based deployment and the ability to  repeatedly deploy discrete fine-grained integration components, cloud-native techniques  ensure a much greater consistency between what was tested during development and what is  live in production. But, DevOps is not just about technology. People are the key to success in DevOps: How they are organized, incentivized, motivated,  and more. It is beyond the scope of this book to delve into how to achieve DevOps  successfully, but we should mention one particular role change that is prevalent.  Operations teams, which used to have their hands full focusing on performing manual  procedures to create and configure environments and reactively chasing down problems  based on alerts, now have an opportunity for a more interesting role. As platforms such as  K8s take away much of the drudgery of building and maintaining environments, the  operations teams are turning their hands to automation. They automate anything that they  see often enough to understand a pattern. They are no longer operations staff: They are  Software Reliability Engineers.  If you have followed all the elements of a cloud-native approach, then you have discarded the  proprietary mechanisms for HA, scaling, deployment, monitoring, and other system  administration tasks. The teams can use generically available skills for container  orchestration for building, deploying, and administering their implementations.  This standardization extends beyond container orchestration into ubiquitous source code  repositories such as GitHub and build tools such as Jenkins. 