In this video, we will learn about achieving agility. The remainder of this module will look at how cloud native culture, processes, and technologies factor into realizing the other four key characteristics that cloud native applications seek to embody. Agility is the primary driving characteristic for everything Cloud Native. Cloud Native applications achieve agility by adopting Agile methodology for software development and delivery that focuses on the following: Instituting a Culture that breaks down barriers between all roles, including project owners, developers, operators, testers, and support that contribute to any phase of the Software Development Lifecycle (SDLC), Working to increase interactions and dialogue around delivering priority changes to the application. Following repeatable Processes that: encourage collaboration to accelerate change and innovation against customer and stakeholder needs to deliver these changes rapidly Inclusive of both human processes like Scrum or Kanban that infuse Agile into the culture and software-oriented processes to quickly integrate and iterate over code changes Invests in Cloud Native Tooling to automate stages of the SDLC especially in the areas that code, build and deploy, that adds to the speed of delivery Let’s look more closely at how Agile Methodology can be applied to the software development lifecycle when creating Cloud Native applications. In general, the Agile practice prioritizes responding to changes at each phase of the lifecycle. Everything starts with an idea. To add an innovation or improvement to the application, all ideas are embraced and discussed to formulate the optimal design approach. Each idea the team agrees to implement necessitates one or more changes to the code. Developers use processes that enable quick iterations over each code change, which is open to review and comment by all interested parties. Developers always include coding and integrating any tests surrounding the change, as well as the minimum necessary documentation describing how various roles use the changed code. Each iteration of an approved and merged code change triggers automated processes leveraging Cloud Native Tooling for marshaling resources needed to build the code and execute all functional or unit tests. Successful builds are rapidly deployed to near-production environments. These deployment environments can be managed using additional cloud native tooling that allows for inspection, monitoring, and further testing to assure there were no negative effects from the change before releasing a new application revision to actual production. Finally, end users, customer advocates, and product representatives, and stakeholders can evaluate and learn from the end results. Developers seek to continuously improve the application and encouraging customer feedback, which in turn generates more Ideas that can be input and prioritized for the next cycle. When agile methodology is put into practice relative to the software-defined lifecycle, as it is with a Cloud Native approach, you will often hear the term “CI/CD” used. In general, it describes automation that emphasizes tooling around the code, build and deploy phases of the software-development lifecycle. The “CI” part of the term is an acronym for Continuous Integration. CI represents the processes that enable all developers of an application to submit source code changes continuously to a source code control system with integrated change management. These code changes can trigger automation to build and test each change as it is submitted and merge it into the application’s codebase upon success. Code changes are made against a single “master” branch. This reduces the complexity from managing the development and maintenance of multiple, often increasingly divergent branches of the code. Most modern source code control systems support “CI”, such as GitHub, GitLab, and Subversion These source control systems also allow for the integration of powerful workflow tools that manage the build and test automation, such as Jenkins or Travis CI or even newer, cloud native technologies like Tekton. The “CD” part of the term typically stands for Continuous Delivery, which refers to the automation that can be triggered against successfully merged application code changes. This automation prepares the built application code for release to an application image repository so that it can be delivered to target environments for further testing and eventual deployment. The intended purpose of Continuous Delivery is to minimize the effort needed to deploy the updated application from Operations teams. This continuous automation typically packages and releases completed application packages, such as a Cloud Native Container images (with appropriate tagging and versioning), on a scheduled basis (such as daily) or can even be triggered on every successful merge. Sometimes the “D” in “CD” is interchangeably used to stand for “Deployment” since Continuous Deployment is often considered linked to Delivery. However, it should be considered as distinct automation that is used to orchestrate and deploy the packaged application to near-production environments for staging and further testing or to actual production environments for customers. Orchestration and deployment can be facilitated by cloud-native tooling such as Helm, Terraform, or Razee which is designed to work with Kubernetes clusters. Module 4 of this course is dedicated to an in-depth look at CI/CD automation processes including demonstrations and hands-on labs. You should now be familiar with: The goals of application agility as applied to the SDLC, How agile methodology affects culture and processes, What constitutes Continuous Integration (CI), Delivery and Deployment (CD) processes, and The role of automation plays in delivering agility as part of CI/CD.
