Skip to content
Class Notes

DevOps and Its Importance Study Notes

DevOps Overview – Covers culture, performance metrics, CI/CD, CALMS model, automation, continuous testing, and frameworks like Agile, SAFe, and SRE. Ideal for modern IT and DevOps foundation learning.

Preview 22 of 71 pages

See the first 22 pages exactly as they appear in the document.

  1. Page 1
    Read page 1 as text

    1 □ What is DevOps? o A cultural and professional movement that stresses communication, collaboration, and integration between software developers and IT operations professionals while automating the process of software delivery and infrastructure changes. It aims at establishing a culture and environment where building, testing, and releasing software, can happen rapidly, frequently, and more reliably. o "Imagine a world where product owners, Development, QA, IT Operations and Infosec work together, not only to help each other, but also to ensure that the overall organization succeeds. By working towards a common goal, they enable the fast flow of planned work into production, while achieving world-class stability, reliability, availability and security." U Why is DevOps Important? o To meet these changing conditions, culture, practices and automation must become more "continuous". U DevOps Performance: o Highly evolved organizations have consistently demonstrated higher performance across four key software performance metrics. o "Organizations that are "good at DevOps" have strong identities, clear responsibilities, autonomy over their own function, and well-defined interaction paradigms and communication channels with other teams." L Development frequency: Low: Monthly or less often. Mid: Between daily and weekly. High: On demand (whenever we want). □ Lead time for changes: Low: Between a week and 6 months. Mid: Less than a week. High: Less than an hour. □ MTTR: Low: Less than a week. Mid: Less than a day. High: Less than an hour. L Change failure rate: Low: Less than 15%. Mid: Less than 15%. High: Less than 15%. □ DevOps Foundation: o With DevOps, people across the IT organization, working together, enable fast flow, feedback, and continuous improvement of planned work into production, while achieving quality, stability, reliability, availability, security, and team satisfaction. □ Practices: Automation, Architecture, Continuous Integration, Continuous Delivery/Deployment, Continuous Testing. □ Culture: Safe, trusting, respectful, collaborative, data driven, continuous improvement, shared accountabilities. o The Three Ways: are DevOps patterns identified in both "The DevOps Handbook" as well as "The Phoenix Project." □ The first way: Systems thinking. □ The second way: Amplify Feedback Loops. □ The third way: Culture of Continual Experimentation and Learning. 1. Continuous Flow

  2. Page 2
    Read page 2 as text

    2 2. Continuous Feedback 3. Continuous Experiment and Learning □ Frameworks: Agile and SAFe, Lean, ITSM, DevSecOps, SRE (Site Reliability Engineering), VSM (Value Stream Management). □ Values: CALMS (see below) o CALMS Model: F Considered the pillars or values of DevOps: Culture, Automation, Lean, Measurement, Sharing (as put forth by John Willis, Damon Edwards, and Jez Humble). □ Continuous Testing: o Continuous Testing is the process of executing automated tests as part of the pipeline to obtain immediate feedback on the business risks associated with a software release candidate. "Shifting left" is about building quality into the software development process. When you shift left, fewer things break in production, because any issues are detected and resolved earlier. Fl Shift Left means: o An approach that strives to build quality into the software development process by incorporating testing early and often. This notion extends to security architecture, hardening images, application security testing, and beyond. U Continuous Integration (CI) o A development practice that requires developers to merge their code into trunk or master ideally at least daily and perform tests (i.e. unit, integration, and acceptance) at every code commit. o Continuous integration (CI) is a development practice that requires developers to commit code into a shared repository (master/trunk) at least daily. o While mostly associated with agile software development, waterfall approaches can also take advantage of continuous integration and testing practices. o Each commit is: □ Validated by an automated build, automated unit, integration and acceptance tests. F Is dependent on consistent coding standards. L Requires version control repositories and CI servers to collect, build and test committed code together. □ Runs on production-like environments. □ Enables early detection and quick remediation of errors from code changes before moving to production. U Continuous Delivery (CD) o A methodology that focuses on making sure software is always in a releasable state throughout its lifecycle.

  3. Page 3
    Read page 3 as text

    3 C Continuous Deployment: o A set of practices that enable every change that passes automated tests to be automatically deployed to production. o Continuous delivery is a methodology that focuses on making sure software is always in a releasable state throughout its lifecycle. o Takes continuous integration to next level. o Provides fast, automated feedback on a system's production-readiness. o Prioritizes keeping software releasable/deployable over working on new features. o Relies on deployment pipeline that enables push-button deployments on demand. o Reduces the cost, time, and risk of delivering incremental changes. □ Continuous Delivery & Continuous Deployment: o Continuous delivery is a prerequisite for continuous deployment into production. □ Continuous Delivery: Dev > Application test > Integration test > Automatic trigger < Acceptance test > Manual trigger < Production. □ Continuous Deployment: Dev > Application test > Integration test > Automatic trigger < Acceptance test > Manual trigger < Production. □ DevSecOps: o A mindset that "everyone is responsible for security" with the goal of safely distributing security decisions at speed and scale to those who hold the highest level of context without sacrificing the safety required. o Goal: Safely distributed security decisions at speed and scale. o Dev: Software. Sec: Safer. Ops: Sooner. "Through Security as Code, we have and will learn that there is simply a better way for security practitioners, like us, to operate and contribute value with less friction. We know we must adapt our ways quickly and foster innovation to ensure data security and privacy issues are not left behind because we were too slow to change." — 2019 MP Infotech Corp. o "I believe the DevOps movement is a new fertile soil from which the build-security-in concept can be reborn, renamed, and remade." Larry Maccherone. o Values: □ Build security in more than bolt it on. C Rely on empowered development teams more than security specialists. F Implement features securely more than security features. □ Use tools as feedback for learning more than end-of-phase stage gates. □ Build on culture change more than policy enforcement. LI Value Stream Management: o Value Stream Management is a combination of people, processes, and technologies that maps, optimizes, visualizes, measures, and governs business value flow through heterogeneous software delivery pipelines from idea through development and into production.

  4. Page 4
    Read page 4 as text

    C Site Reliability Engineering (SRE) o The goal is to create ultra-scalable and highly reliable distributed software systems. o SRE's spend 50% of their time doing "ops" related work such as issue resolution, on-call, and manual interventions. o SRE's spend 50% of their time on development tasks such as new features, scaling or automation. o Monitoring, alerting and automation are a large part of SRE. □

  5. Page 5
    Read page 5 as text

    5 Questions: Q) Which of these is a value of DevSecOps? A) Build Security In. Q) What does CALMS stand for? A) Culture, Automation, Lean, Measurement, Sharing Q) Which of the following are attributes that describe DevOps? A) All of the above: Achieve world class stability, reliability, availability and security. Product owners, Development, QA, IT Operations and InfoSec work together. Working on a common goal to enable fast flow of planned work. Q) Which best describes The Second Way of DevOps? A) Create short feedback loops. What is the second way of DevOps? The Second Way: Feedback loops and the need for amplification. The Second Way places value on providing and receiving quick feedback on a continual basis. The aim is to improve work quality while also preventing repeat problems. When feedback loops are amplified, mistakes can quickly be identified and fixed. Q) Which of these is NOT a primary practice of DevOps? A) Continuous Planning

  6. Page 6
    Read page 6 as text

    6 Module 2 □ Software Source and Artifacts Control: o Software source code and artifacts control systems and practices ensure that code changes, and executable binary artifacts that result from builds, are saved, managed and reproducible. This is the single source of truth for software. ALL assets should reside in a managed repository and include all types of assets. C Software Source and Artifacts Control Importance to DevOps: o Enables collaboration between developers and other stakeholders in the DevOps environment. o Enables orderly flow of software changes. o Developers can make changes in their code modules in parallel and integrate their changes together to make a version that includes all changes. o Source and image changes can be labelled for testing, tracing, auditing and debugging. o Enable restoring to a specific "known good" version in case of problems. o Governance and security. C What is Software Source Control? o Also known as source code version control or source version management (SVM) o Store, track and manage versions of software source code o Enables branches and merges of source code versions □ Software Source Control: Tool Features: o Database of source code files o Meta data (labels) and tags identify versions and changes information o Merge changes o Make branches o View dependencies between modules o Push, Pull, Copy changes o Integration with other tools DevOps toolchain o Access & permissions management o Notifications and alerts o High availability, replication, restore □ Example Tools: □ Azure DevOps Server □ AWS Code Commit □ Git □ GitHub U GitLab □ Perforce (P4) □ Subversion (SVN) □ Software Source Control Practices: o Developers "commit" changes to trunk at least once per day. o "Pull-Request protocol" ensures all commits are checked by the SVM system prior to completing the merge to the continuous integration "mainline" or "trunk" branch. o Each commit checks include verifying the code meets standards for documentation and testing (E.g., source code analysis, unit testing, compilation checks, functional integration tests.)

  7. Page 7
    Read page 7 as text

    7 U What is Software Artifacts Control? o Artifacts Control is also known as image management or artifact repository. o Store, track and manage versions of binary executable software modules and containers that result from "builds" of source code. o Repository for versions of images and containers that are used for deployments to test and production environments. □ Software Artifacts Control Practices (cont) o The result of every build and container are saved in the repository. o Images and containers are signed to ensure tracing and auditing. o Access and files are secured with access lists and permissions. o Backups and restores are tested periodically. □ Software Source and Artifacts Control Support High Availability: o If a failure is detected anywhere across the pipeline, the SVM and Artifact repository can restore a prior working version quickly. o Replication and backups prevent loss. □ Software Source and Artifacts Control Support Application Security and Governance: o Labels ensure versions and changes are traceable and auditable. o Access controls prevent unauthorized access and changes. □ Source and Artifact Control Benefits: o Software and Artifacts controls are crucial to DevOps. o Tools for version management of software source code and artifacts with executable binary images enable orderly flow, collaboration, pipeline integration. Security, governance, compliance, high availability and recovery features. Artifact Repository: Store for binaries, reports, and metadata. Example tools include JFrog Artifactory, Sonatype Nexus. □ Ci/CD Pipeline: o CI/CD Pipelines, also known as Continuous Delivery Pipelines constitute the core of DevOps processes in software engineering, CI/CD is the combined practices of continuous integration (CI) and either continuous delivery or continuous deployment (CD). L Why are CI/CD Pipelines Important? o CI/CD pipelines bridge gaps between development and operation activities and teams by enforcing automation and monitoring builds, tests and deployment of applications. □ CI/CD Pipeline Practices: o CI/CD pipelines are made of a series of tools called toolchains that connect through APIs. o Developers test their code changes in their private environment prior to committing the changes for integration. o A developer's "commit" action automatically triggers a pull-request to the CI process which checks, merges source code with trunk and builds new candidate artifacts. o The back-end CD process verifies the candidate artifacts, prepares for deployment and post-deployment tests. o The decisions and actions to effect deployment to production may be automated and may require a manual approval. □ CI/CD Pipeline Benefits o Processing work in small batches has many benefits:

  8. Page 8
    Read page 8 as text

    8 L Fault isolation is quicker. □ Mean time to resolution (MTTR) is shorter. □ Testability improves. □ Time to detect and correct production escapes is shorter. □ The backlog of non-critical defects is lower. □ The product improves rapidly. F Smaller units of change are less disruptive. □ Product feature velocity is high. □ Seamless, deployments to production. □ Release cycles are shorter. □ End-user involvement and feedback leads to usability improvements. o CI/CD Tools and Toolchains F Each stage in a Cl/CD toolchain have specialized tools that perform the tasks assigned to each stage. o CI/CD Pipeline Tools Example Selection Criterion □ Example factors for selecting DevOps Tools: □ Compatible with application tech stack. □ Compatible with Clouds and OS versions. □ Control and observe tool through an API. I I Can be deployed in the cloud. □ Can be packaged in containers. □ Scale as elastically as the infrastructure. □ Fault-tolerant and persistent. □ User licenses do not block auto-scaling. □ Pre-tested and supported integrations. □ Metrics track tool usage and errors. □ Cost to purchase and maintain. CI/CD Pipelines, also known as Continuous Delivery Pipelines: A continuous delivery pipeline refers to the series of processes that are performed on product changes in stages. A change is injected at the beginning of the pipeline. A change may be new versions of code, data, or images for applications. Each stage processes the artifacts resulting from the prior stage. The last stage results in deployment to production. o Application Release Automation (ARA) □ ARA tools orchestrate resources, automate pipeline stage checks, regulates flow of changes and provides visibility of the flow across the end-to-end CI/CD pipeline. o Application Release Automation (ARA) Capabilities: L Many tool integrations are supported. □ Virtual and cloud infrastructures are supported. □ Pipelines are configured as code. □ Test environments are referenced abstractly. □ Templates and tools used to onboard new applications. C Black-out periods are defined for maintenance windows. F Pipelines are abstracted (decoupled) from the applications. □ Manual tasks are integrated into pipeline steps. □ Highly scalable, secure, and configurable configurations are supported.

  9. Page 9
    Read page 9 as text

    9 L Environment modeling and workflow-management capabilities. o Application Release Automation (ARA) Benefits □ ARA make DevOps application activities more manageable and visible. □ Releases and pipelines can be specified as code. □ Importing data from other tools simplifies modeling of applications and microservices. H Easy for DevOps users to monitor and manage pipeline activities. □ Self-service capabilities simplify onboarding users and applications. Application Release Automation (ARA) or Orchestration (ARO): Controlled continuous delivery pipeline capabilities including automation (release upon code commit), environment modeling (end-to-end pipeline stages, and deploy application binaries, packages, or other artifacts to target environments), and release coordination (project, calendar, and scheduling management, integrate with change control and/or IT service support management). o Value Stream Management (VSM) C VSM tools provide orchestration and analysis capabilities over one or more continuous delivery pipelines. □ Benefits: o Manage services that consist of multiple application pipelines. o Monitor aggregate resource utilization. o Optimize resources across multiple pipelines. □ Example VSM tools: Plutora, Tasktop, Service Now, DigitaLai, CloudBees Value Stream Management : Value Stream Management is a combination of people, processes, and technology that maps, optimizes, visualizes, measures, and governs business value flow through heterogeneous software delivery pipelines from idea through development and into production. Value Stream : All of the activities needed to go from a customer request to a delivered product or service. Mean Time to Repair/Recover (MTTR): Average time required to repair/recover a failed component or device. MTTR does not include the time required to recover or restore service.

  10. Page 10
    Read page 10 as text

    10 Questions: Q) Application Release Automation tools do what? A) Make CI/CD pipeline flow visible. Q) What does CI/CD stand for? A) Continuous integration and continuous delivery. Q) Which of these is NOT a benefit derived from CI/CD pipelines? A) Feature velocity is slower. Q) Why is Source and Artifacts Control important to DevOps? A) Enable restoring to a specific "known good" version in case of problems. Q) Which of these is a best practice for software artifacts control? A) Access and files are secured with access lists and permissions.

  11. Page 11
    Read page 11 as text

    11 Applications Architectures & Continuous Integration: E One of the most important and misunderstood subject of DevOps. What is Application Architecture? □ Application architecture describes the patterns and techniques use to both design and build an application or solution. Fl Architecture aligns to strategic goals of an organization. □ The architectural patterns and blueprints selected need to support organizational goals. □ There are many types of architectures with some being much more prominent based on relationship between components or services. Architectural Pattern: Service Relationship: Monolithic Tightly coupled N- tier/Multi-tier Tightly coupled Event-driven Loosely coupled Microservices Decoupled "If frequent release of new features is a strategic goal, event-driven or Microservices patterns may be a great choice!" Application Design for Continuous Delivery U Monolith and legacy products can benefit from DevOps and CI/CD, but modular, immutable architectures are most readily suited for continuous delivery. U Best DevOps performance is achieved for products that are designed in modular fashion using service-oriented architectures, microservices patterns, and 12-factor apps design practices and packaged into small containers. Key Principles of Application Architectures I I Process Considerations: o Build quality in o Work in small batches o Recognize that automation can do repetitive tasks while only people can solve problems o Relentlessly pursue continuous improvements Fl How NOT to do Continuous Delivery: o Monolithic architecture o Water-scrum-fall o No deployment pipeline "...trying to deliver plans that were developed a year or 18 months in the future. And then when you integrate your code it is still taking days, maybe weeks, maybe months or even quarters to release code." 12-Factor App Design Practices 1 . Codebase: One codebase tracked in revision control, many deploys. 2. Dependencies: Explicitly declare and isolate dependencies.

  12. Page 12
    Read page 12 as text

    12 3. Configuration: Store config in the environment. 4. Backing Services: Treat backing services as attached resources. 5. Build, Release, Run: Strictly separate build and ran stages. 6. Processes: Execute the app as one or more stateless processes. 7. Port binding: Export services via port binding. 8. Concurrency: Scale out via the process model. 9. Disposability: Maximize robustness with fast startup and graceful shutdown. 10. Dev/prod Parity: Keep development, staging, and production as similar as possible. 11. Logs: Treat logs as event streams. 12. Admin Processes: Run admin/management tasks as one-off processes. 12 Factor App Design Practices Benefits: benefits of 12-factor Apps Practices: □ Declarative formats support automation which reduces setup time and cost. E Clean contract with the underlying operating system offers portability between execution environments. □ Deployment on modem cloud platforms, reduces administration costs. □ Minimizes divergence between dev and production environments. E Scale up without significant changes to tooling, architecture, or dev practices. Feature Toggles (Config Flags) Practices: Put every software feature behind feature toggles because: □ Allows safe work in production. □ Only deliver changes to the right people at the right time. □ Same code can support feature variation for specific environments. U Support feature variations for specific users. □ Integrates with A/B test framework. □ Can be used for gradual, controlled rollout of new features. Design Patterns: Typical solutions to common problems that appear in software design; patterns are like blueprints that you can tailor to your particular need. U Concept of design patterns came from building architecture from a book called "A Pattern Language: Towns, Buildings, Construction" by Christopher Alexander. E The idea was picked up by four authors in 1994 - Gamma, Vlissides, Johnson, & Helm - and applied to software engineering. What's included in a design pattern? □ Intent - brief description of the problem and the solution. □ Motivation - further explains the problem and how the solution addresses the problem. E Structure - shows the organization of the code into classes or file and how they relate. E Code Example - shown in popular languages to make it easier to understand the pattern. o Design Patterns can differ by language and there are multiple categories Design Pattern Library Practice: Benefits of Design Patterns:

  13. Page 13
    Read page 13 as text

    13 U On-board team members quickly C Quickly rough out designs □ Avoids duplication of effort □ Consistent style □ Consistent behavior Architect For: □ Test-ability □ Automation-ability □ Deploy-ability □ Monitor-ability □ Configure-ability C Evolve-ability Microservices: Microservices is an architecture pattern for building loosely coupled distributed autonomous services that are: □ Well-bounded / cohesive. □ Consumed via API. U Independently developed. □ Independently deployable. Benefits: □ Productivity Fl Better resource utilization U Easy to package / deploy □ Easy to change Microservices Prerequisites : The complexity of working with a distributed system dictates that achieving the benefits of microservices require mature continuous delivery pipelines for each microservice, including: L Clear understanding of user requirements □ Continuous Integration □ Continuous Testing □ Continuous Deployment □ Continuous Monitoring I I Elastic infrastructures □ Each microservice has its own database and repository Microservices Practices: □ Each microservice has its own CI/CD pipeline. □ Keep test environments as close to production as is practical. L One service per host minimizes the impact of one service on others and the impact of a host outage. □ Use VMs/containers to make deployment and management easier.

  14. Page 14
    Read page 14 as text

    14 o Containers map very well to microservices. o "Immutable servers." Monolith to Microservices Design Strategy: □ Do it incrementally, not as a big-bang rewrite. □ This often results in hybrid approach with some microservices and some legacy. □ Look for seams - areas of code that are independent, focused on a single business capability. □ Domain-Driven Design and the notice of Domain Contexts is a useful tool. □ Look for areas of code that change a lot (or need to change.) □ Don't ignore organizational structure (Conway's Law). □ Dependency analysis tools can help identify partitions but are no panacea. Microservice Data Considerations: □ A leading practice called "Poly repos" has each micro-service with its own database to help assure independence. □ A Relational Database Management System (RDBMS) is typically a source of undesirable dependency coupling. LI Understand your schema: o Foreign Key constraints o Shared mutable data o Transactional boundaries □ Avoid distributed transactions Fl Split data before you split code U Consider NoSQL instead of RDBMS Microservices Cautions: □ There are more moving parts to co-ordinate operationally. U Changing requirements may impact multiple services. □ Rigorous failure handling and resiliency is critical. L Reporting will need to change - you probably won't have all the data in a single place or even a single technology. □ Success depends upon network reliability. □ Microservice catalogs can help tack services across clusters. Microservices Concerns: □ Config Management □ Service Discovery & LB □ Resilience & Fault Tolerance □ API Management □ Service Security □ Centralized Logging □ Centralized Metrics □ Distributed Tracing □ Scheduling & Deployment

  15. Page 15
    Read page 15 as text

    15 U Auto Scaling & Self Healing Microservices and Containers: □ Containers: An approach to software development that packages pieces of code so that they can quickly be plugged into and run on an Operating System (OS) such as Linux. L Containerization is a lightweight alternative to full machine virtualization. □ It involves encapsulating an application in a container with its own operating environment. □ This provides many of the benefits of loading an application onto a virtual machine as the application can be run on any suitable physical machine without worries about dependencies. Microservices and Containers 2 Containerized microservices offer the following benefits: □ Infrastructure agility □ Reduced setup and execution time for build and test □ Immutable server simply replaced as needed. □ Easy replication □ Applications run without worrying about the underlying stack U Easy to automate deployment What is Continuous Integration (CI)? In software engineering, continuous integration (CI) is the practice of merging all developers' working copies to a shared mainline several times a day. Benefits of Continuous Integration: □ Improved communication □ Accelerates releases L Improved mainline stability □ Fast error detection I I Improved quality U Improved governance and compliance E Lower total cost of software □ Improved job satisfaction CI System Components □ CI works as an automated system, consisting of the following components: o Source Version Management (SVM) o CI orchestration engine (CI Server) o Build and test infrastructure, tools and processes o Artifact Repository How Does CI Work? □ Commits:

  16. Page 16
    Read page 16 as text

    16 o Developers "commit" changes at least once per day to the Software Version Management System. o "Pull-Request protocol" ensures all commits are checked by the SVM system prior to completing the merge to the continuous integration "mainline" or "trunk" branch. o A change that affects a dependent code module automatically triggers a new build for the dependent module for testing. How Does CI Work? □ Checks, Build and Tests o Developer submits Pull request. o The CI server automates and orchestrates the CI processes. o Static checks are performed on the code (E.g., code logic and exceptions). o Builds produce executable code images. o Dynamix tests including unit tests and functional "smoke" tests are performed on the images. How Does CI Work? □ Images, Merges, Reports o Images that pass the tests are stored in an Artifact Repositoiy as potential release candidates. o The verified code changes are merged into the mainline code in the SVM. o All the steps are made visible in a Dashboard. o Pull request is accepted. o Any exceptions or failures are reported in alert messages. CI Workflow 1. Verify merge gate thresholds are satisfied. 2. Merge changes with mainline repository. 3. Run static scans on merged code. 4. Orchestrate build resources. 5. Create the build. 6. Save build artifacts to artifact repository. 7. Run unit tests. 8. Save unit test results to artifact repository. 9. Release the build resources back to the pool. 1 0. Orchestrate functional test resources. 11. Run functional tests. 12. Perform analysis and assessments. 13. Save test results to artifact repository. 14. Remediate any problems discovered. 15. Promoted the build to the delivery stage. 16. Release test resources back to the pool. Branching and Merging Practices One mainline "trunk"

  17. Page 17
    Read page 17 as text

    17 U Code is continuously integrated. C Tests run on integrated codebase. □ Developers see others changes immediately. □ Avoids "merge hell" at the end. □ Instant feedback about application status. o Source code, images and test versions in same branch structure ensures consistency. "No Feature Branches" Best Practice □ No separate feature branches. □ Merge when code is pulled from mainline (trunk branch). □ Branch in-code (within mainline) using feature toggles (i.e., config flags). F Eliminates merging issues and keeps everyone accountable. Fl Simple and easy to understand. Cl Inputs are Gated Practice - mainline merges are automatically gated by thresholds: □ Code inspection results. Fl Unit test results. C Static analysis metrics. □ Cyclomatic complexity metrics. □ Pre-flight functional test results. □ Code coverage results. □ Reason for change documentation. High priority violations stop a merge. Warnings are issued for lower priority violations. Continuous Integration (CI) Summary: F Cl is the heart of DevOps. □ Automation of the commit, build, test, release image creating and reporting processes, combined with CI practices assure that mainline is stable and continuously available for new changes. □ CI provides many benefits and is a pre-requisite for faster time for new, high quality, secure, compliant code releases. Summary: Architecture : The fundamental underlying design of computer hardware, software, or both in combination. Container: Away of packaging software into lightweight, stand-alone, executable packages including everything needed to run it (code, runtime, system tools, system libraries, settings) for development, shipment, and deployment. Unit tests : The purpose of the test is to verify code logic. Microservices: A software architecture that is composed of smaller modules that interact through APIs and can be updated without affecting the entire system.

  18. Page 18
    Read page 18 as text

    18 Q: Which of these is NOT a benefit derived from CI/CD pipelines? A: Feature velocity is slower. Q: An enterprise wants to implement CI for a large group of business applications. Where should the they start? A: Model the Value Streams. Q: Which of these is a best practice for software artifacts control? A: Access and files are secured with access lists and permissions. Q: Which of the following is NOT an attribute of microservices? A: Other applications control and observe microservices using programs compiled with the microservices code. Q: What does CI/CD stand for? A: Pipeline of Continuous Integration and Continuous Delivery processes.

  19. Page 19
    Read page 19 as text

    19 Module 4: Continuous Testing What is Continuous Testing? □ Continuous Testing is a quality assessment strategy in which most tests are automated and integrated within a DevOps value stream. Fl DevOps testing assessments are performed "continuously" on incremental product changes using a production equivalent environment for each of the end-to-end DevOps pipeline stages. Continuous Testing Myth □ Myth: Continuous testing is a phase between DevOps pipeline integration and delivery stages. Fl Truth: Continuous testing is implemented as part of all DevOps pipeline stages, end-to-end, in accordance with a "continuous" testing strategy. Holistic Testing □ Planning starts at design. □ DevOps practices like TDD, BDD, and CI. I I Static code analysis is a form of testing! U Finding and remove redundant test cases. □ Once you deploy, monitor and observe. □ Test in production using feature toggles. □ Learn from data about production usage and behavior. □ Emergence of TestOps. Continuous Testing Tenets □ Continuous testing, when engineered well, is implemented in accordance with five Tenets. o Shift left o Fail often o Relevance o Test fast o Fail early □ Continuous Testing Tenets - Shift Left o What? Conduct each test as early in the pipeline as possible. o Why? Defects are detected and corrected more efficiently compared to strategies in which many tests are concentrated nearer the end of the pipeline. o How? Concentrate more complete testing as early as possible in the SDLC. □ Continuous Testing Tenets - Fail Early o What? Test the most likely problem cases during the earliest possible stage. o Why? Defects are corrected more efficiently compared to strategies in which many tests are concentrated nearer the end of the pipeline. o How? Include system and regression tests during Pre-Flight testing using a production equivalent environment. □ Continuous Testing Tenets - Fail Often o What? Run tests frequently and with many different conditions.

  20. Page 20
    Read page 20 as text

    20 o Why? Defects are detected and corrected more efficiently compared to strategies in which many test conditions are concentrated nearer the end of the pipeline. o How? Run all tests, including those run during Pre-Flight, CI and CD phases, in production-equivalent environment conditions. □ Continuous Testing Tenet - Test Fast o What? Accelerate the time for test execution. o Why? Problems are fixed quicker when they are found quicker. o How? Schedule tests frequently, for each change or small number of changes rather than waiting for large batches of changes. □ Continuous Testing Tenet - Relevance o What? Focus on the most important tests and results o Why? Tests and test results are continuously focused on the highest priorities most likely to add value to the product and not waste time on lower value items. o How? Select tests which best match the changes being processed and assess test results by focusing on the most relevant result data. Test Creation Strategies Fl Continuous Testing requires the creation and maintenance of automated tests. There are a variety of methods for creating automated tests including: □ Scripting automated tests. □ Keyword-driven tests. □ Interactive capture/replay tests. □ Test driven development (TDD). F Model-based tests. L Behavior-based tests. □ Scripting Automated Tests o Automated tests, when scripted correctly, save a lot of time. However, there are many pitfalls to avoid. The Key is knowing which tests are most important to automate. o Good candidates for automated testing include: □ Repetitive tests that are used often. F Tests that require multiple data sets. □ Changes for code areas that are high risk. □ Tests impossible to perform manually. □ Tests that ran on multiple hardware or software platforms and configurations. □ Tests that take a lot of effort and time when manual testing. □ Keyword-Driven Tests (Table driven testing) o Keyword-Driven testing is also known as table-driven testing or action-word-based testing. This methodology uses keywords (or action words) to symbolize a functionality to be tested. The test execution logic is hidden in the code that implements the keyword. o Advantages: L Suitable for both manual and automated testing. □ Easy to understand test descriptions. □ Tests are maintainable and tolerant to changes of the application. □ Open and extensible frameworks unites tools, assets, and data. o Disadvantages:

  21. Page 21
    Read page 21 as text

    21 L Requires keyword specific tools. □ Keyword code logic must be maintained. □ Interactive Capture-Replay Testing o Using a capture and replay tool, a tester operates an EUT, records (captures) the inputs and outputs, replays the input actions and compares the responses to captured response outputs. o Advantages: L Easy to create an executable test and test data without coding. □ Suitable for GUI, CUI, APU and protocol testing. o Disadvantages: □ Requires manual editing of the script to make it reusable and maintainable with different data sets. U Test-Driven Development (TDD) o With Test-Driven Development (TDD) the tests are created in advance of the code that is to be tested. Tests DRIVE actions, dictate the code design and determine when the code is complete. o Benefits: □ Guarantees code changes have some test coverage. □ Unambiguously defines the code requirements. L Encourages collaboration between QA and designers. o Test-Driven Development and design applies to unit tests, functional tests and acceptance tests but is most often applied to EUT code level testing during development. □ Test-Driven Development (TDD) Practices o Write tests that fail before new functional code. This is different than unit testing where the tests are written afterwards. o Use TDD when the design goals are understood. Otherwise use unit testing. o Use real objects if possible and a double (code substitute) if it's awkward to use the real thing. o Use code stubs and "Mock Objects" (Mocks) to substitute for external dependencies or to isolate internal dependencies. F Stubs verify states of the EUT. □ Mocks verify behavior of the EUT to ensure it made correct calls on the mock object. o Treat aggregated objects as a single EUT - do not breakup encapsulated objects. o Reuse Assertions code to validate states of an EUT. □ Model-Based Tests o Model-Based testing is the automatic generation of tests, using models of system requirements and behavior. Models represent an abstraction of a system from a particular perspective. Models support investigation, construction, and prediction of the modeled system. o Advantage: □ Tests are created automatically Better than TDD for addressing bigger issues such as the overall design, how people will use the system, and the UI design. o Disadvantages:

  22. Page 22
    Read page 22 as text

    22 L Requires substantial up-front effort to build and maintain models. Test coverage depends on the validity and completeness of the model. Complex systems require complex models. □ Behavior-Based Tests o Natural language descriptions expressing EUT behavior and expected outcomes are converted into tests which execute in a tool. o Advantages: L Specification and test documentation are aligned. □ Executable specifications encourage closer collaboration, helping teams keep the business goal in mind at all times. C Developers, testers and business folks can explore the problem domain, and collaborate to produce concrete examples that describe the behavior they want. F Supports a close relationship between acceptance criteria for a given function and the tests used to validate that functionality. o Disadvantages: □ Requires all team members to learn special methods and tools and write and maintain complete behavior descriptions. □ Test Acceleration Strategy o Testing needs to keep up with the ever-increasing demand for speed. What can be done to accelerate continuous testing? □ Organize the team for speed (reduce bottlenecks and handoffs). □ Select powerful resources (Vertical scaling). □ Run more tests in parallel (Horizontal scaling). □ Choose test tools designed for fast execution. □ Organize test schedules and test suites to fail early. C Design test cases to fail early. □ Arrange test results to minimize wait times. □ Test Results Analysis Strategy o What can be done to ensure continuous test results analysis keeps pace with accelerated continuous testing? F Determine clear responsibilities and define time budgets and targets for responding to problems found by testing. F Design test scripts for efficient test results analysis. □ Choose test tools that are designed for fast test results analysis. □ Choose and configure test analysis tools to process results aa they are available. □ Configure workflows flow for optimum test results analysis. C Test Results Practices o Test results include verdicts (pass, fail, inconclusive). o A common framework is used for reporting test results. o Dev, QA, and Ops stakeholders can access test results. o Automated and manual test results, are accumulated and reported. o Test results are stored in a version management system. o Test trend analysis are produced for tests. o Test results report formats summarize information and allow telescoping to details. o Test results thresholds trigger actions when thresholds are exceeded. U Test Management o Tests are as important as the code because the tests are the validation of the code.

49 more pages in the full document

Unlock it once and it stays in your library, ready to chat with or turn into flashcards.

Unlock the full document

More Information Technology study materials

See all

Study this document with CramX

Once it is in your library, every tool can work from it.