This section covers analyzing and optimizing technical and business processes in the exam guide outline. Let's start with a case that will illustrate business requirements. You may have seen this situation before, the customer experiences that pushing to production is scary because you'll never know when things might break. This customer could only push to production once a month. There was significant risk of downtime and when there was downtime the application breaks and that impacts revenue. So the summary is we need to be able to develop and deploy features needed to present to production without it being an event. A customer had this interesting business requirement. Pushing to prod is a big event and happens once a month. Significant risk of downtime due to unforeseen issues. Downtime exceeds SLAs that have revenue impact. Need to develop and deploy features without burning the house down. Pushing to production should be a non-event. There are two passes through the problem in the architectural process. First, there's the business pass which includes both the business challenge and the people processes understanding what roles there are and what actions that people need to be able to take. And then there's the technical pass which is mapping all of these needs and procedures to a technical solution. We mapped that to technical requirements like this. Establish a CI/CD pipeline. Single source repo per product, git-flow as branching model. Automate build, self-testing, rapid. Automate deployment. Setup robust monitoring, logging and alerting for visibility. Promote team culture. Test Driven Development. Push often, address broken builds immediately. Transparency. Change management, and release process. To push to production on demand, we needed to analyze the development process. We figured out that a single source repo made the most sense for the whole team. We decided to go with git-flow as a branching model instead of other kinds of development. We automated the build process, but also we made sure that the builds were self testing using salt test coverage. And we measure the build process to make sure that it was rapid. We also automated the deployment of the solution software, couple of these automation with monitoring login and alerting. And you get a nice build and deploy system that can be headed off to a team. But that doesn't solve the entire problem. The system has to be used and this team was not going to be accustomed to using the development paradigm we've implemented. So we also needed to do was to enhance their processes. This primarily had to do with how test and development work together. In the new paradigm, they would start writing the testing along with development. The new way was to push reproduction off and then push early, and as soon as something would break, fix it. This meant a new team culture, one of accountability and transparency where all the stakeholders could participate in identifying and resolving a problem. And that meant change management and leadership buy-end was necessary for the technical solution to be successful And this is how we implemented that technical requirement. Cloud Source Repositories for hosting of repositories. Container Builder that builds the Docker container images. Container Registry that hosts these container images. Google Kubernetes Engine, +Helm for running and managing. And Spinnaker for CDP for continuous delivery. Cloud Load Balancing, Stackdriver, Cloud IAM, and Service Accounts and manageability constructs for proper visibility.