Introduction To DevOps Flashcards
(95 cards)
1
Q
DevOps adoption
A
- People - Alignment of teams
- Process - Alignment of process, Measurement & optimization
- Technology - Alignment of capabilities, Tool stack & implementation
2
Q
Technology challenges
A
- Lack of automation in the software development life cycle, hence loss of quality due to error prone repeatability of steps
- Defects generated due to inconsistent environments for testing and deployment
- Delays in testing due to infrastructure unavailability
- Brittle point-to-point integration between modules
3
Q
DevOps is…
A
A set of capabilities, across the IT Value Stream (PLAN – BUILD – RUN) which enhances throughput, quality and business value
4
Q
Minimum Dev Capabilities
A
- Version Control
- Static/Dynamic Code Quality Analysis
- Build Automation
- Baseline in Artifact Repository
- Continuous Integration
5
Q
Minimum Test Capabilities
A
Functional/Acceptance test
6
Q
Minimum Infrastructure Capabilities
A
- Database deployment
- CD Automation
- Release Management
7
Q
Minimum Ops Capabilities
A
- Incident Management Tools
- Monitoring and Dashboard
8
Q
Good to have Business Capabilities
A
- Acceptance Testing
- Rapid Prototyping
9
Q
Good to have Dev Capabilities
A
- Code coverage
- Code review
- Unit testing
10
Q
Good to have Test Capabilities
A
- Test and Defect Management
- Test Data Management
- Service Virtualization
- Performance Testing
- Security Testing
11
Q
Good to have Infrastructure Capabilities
A
- Infrastructure Layer
- Environment Management
- Containerization
12
Q
Good to have Ops Capabilities
A
Support Analytics
13
Q
Policies/Procedure/Methods Business
A
- Agile
- Big Room Planning
- Lean
14
Q
Policies/Procedure/Methods Dev
A
- Agile
- Feature Toggle
- Incremental Design
- Micro Services
15
Q
Policies/Procedure/Methods Testing
A
Progressive Test Automation
16
Q
Policies/Procedure/Methods Infrastructure
A
- On demand/cloud based Infra
- Infra-as-code
- Just enough Infra
17
Q
Policies/Procedure/Methods Ops
A
- Predictive Monitoring
- Self Healing
18
Q
Agile
A
Time boxed, iterative approach to software delivery that builds software incrementally from start of the project, instead of trying to deliver it all at once near the end.
19
Q
Big room planning
A
Brings all the stakeholders who are responsible for delivery of software (business, dev, test, program management teams) together in a single room for about two days
20
Q
Lean
A
State of a project achieved by collaboration, by ‘shifting left’ operational concerns early in the development lifecycle, by eliminating waste, rework and over-production i.e. using Lean Principles in DevOps
21
Q
Feature Toggle
A
Releasing features to a selected cohort to get their responses prior to release to entire user base
22
Q
Incremental Design
A
Based on SOLID principles
23
Q
SOLID
A
- Single responsibility principle
- Open closed principle
- Liskov substitution principle
- Interface segregation principle
- Dependency inversion principle
24
Q
Micro services
A
An architectural style to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms.
25
Microservices Components
* Client-side user interface
* Database Server side application
26
Client-side user interface
Manages the views and the user interface of the application
27
Database
Stores the data in a relational database
28
Server side application
Handles HTTP requests and executes the domain logic, extracts and updates data from/to the database and provide the HTML views
29
Single responsibility principle
A class should have only one reason to change
30
Open closed principle
Software entities should be open for extension, but closed for modification
31
Liskov substitution principle
Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it
32
Interface segregation principle
Clients should not be forced to depend upon interfaces that they do not use
33
Dependency inversion principle
High-level modules should not depend on low-level modules. Both should depend on abstractions.
34
Continuous Integration Pipeline
A software development practice adopted as part of extreme programming.
Version source code -\> Code Quality Analysis -\> Unit Testing -\> Code Coverage -\> Create Executable -\> Baseline the Executable
35
Progressive Automation
One of the automation methods where the test modules are tested in various stages of software development. Test code is written simultaneously with the development code.
36
Continuous and automated testing
Involves using automated testing tools which can execute tests, provide outcomes of the tests in the form of reports and can be run repeatedly.
37
Service Virtualization
Helps in simulating application dependencies and begin testing earlier.
38
On-demand infrastructure
A model where computing resources are made available to the user as needed.
39
Infra-as-code
Programmable infrastructure which involves writing code using a high level or descriptive language to manage configurations and also provision infrastructure and deployments in an automated fashion.
40
Just enough infra
Involves provisioning infrastructure from a cloud or a virtual setup when and as much required.
41
Continuous Deployment Automation
Allows constant flow of changes into production through an automated software production pipeline called "CD Pipeline" This involves Continuous Validation (CV) followed by Continuous Delivery.
42
Release Management
The automated tools for release management allow the integration of the management and execution of releases.
43
Database deploy
The automated database deployment tools generate a single deployment script that contains the meta data and structure changes.
44
Infrastructure layer and environment management
Managed by tools like Chef which help spinning of virtual machines, syncing them, help make changes across multiple servers etc.
45
Containerization
Allows virtual machines to share a single host operating system and relevant binaries, drivers etc.
46
Predictive Monitoring
Analyze various elements of the IT environment in a way that enables the IT teams to predict issues before it turns into a full-fledged issue and disrupts the services
47
Self-healing
Involves making the system take decisions based on continuous checking and optimization of its state and adapt to changing conditions.
48
Incident Management
Centralized incident management solutions avoids redundant alerts.
49
Support Analytics
Tools for support analytics do a deep search for data, do centralized logging and parsing and display the data in a neat way.
50
Monitoring Dashboard
A dashboard provides a complete view of the pipeline. The dashboard can be based on different perspectives.
51
Principles for stack tools
Repeatability Reliability End to end automation 100% source control Auto build quality Done is released Continuous feedback Customer appetite for tooling
52
Done is released:
Pipeline should ensure that "done-ness" as per definition of done is only released to production
53
Continuous Integration steps
1. The CI tool invokes the static code analysis tool. This checks the quality of code against the set rules.
2. The CI tool then invokes the automated unit test cases. Only if they pass or as per the gating criteria set, the next stage is invoked.
3. In order to check if the unit test cases cover the code, the code coverage tool is invoked next by the CI tool.
4. The CI tool then invokes the build script for building the executable file. At the end of the integration, the binary file is baselined into a binary repository.
54
Continuous Delivery stesp
1. The continuous integration tool tool may trigger the environment provisioning tool which provides provisions and configures the test environments (functional, performance testing etc)
2. The CI tool then triggers deployment automation tool to deploy the application into the provisioned environment and executes the automated QA test cases and if the gating conditions are met for the execution of the tests moves to the next stage
3. The CI tool then invokes tools to provision the pre-production deployment environment. The deployment tool deploys the working version of the software to the pre-prod environment configured and runs all the automated tests.
4. If the acceptance tests pass, steps 7 and 8 are repeated for production environment and the software is deployed automatically after going through release management process
5. The workflow and approval mechanisms are configured using and in release management tools. The changes done get reflected in production environment i.e. release to production Note: If deployment process is also automated seamlessly, then it is called continuous deployment.
55
Application life cycle management(ALM) tool
Can be used for tracking and managing the user stories, team activities and ceremonies.
56
Static and Dynamic code analysis
involves the execution of quality rules as defined by the static code analyzer on the source code and test cases to ensure that the code meets quality guidelines for emergent design and incremental software development.
57
Code Coverage
Check the coverage of the source code by the test cases. Help checks the quality of the test cases.
58
Build automation
The process of code being integrated and built by automated tools. Tools help creating versions of the binary file, and this process is done through a build script.
59
Baseline in artifact/binary repository
Artifact/Binary repository ensures
* Dependencies (libraries) are version controlled
* Dependencies can be shared
Stores information about
* User who triggered the build
* Modules which were built
* Source control(branches) that were used
* Dependencies used
* Environment variables
60
Team structure model 2: One team with Ops extension
Horizontal Ops team forms a backbone for all development teams It provides 24x7 support and performs the tasks which have larger impact on IT Few Ops team members can become part of Dev team and perform tasks which are application specific Ops team members can become part of Dev team Ops representative will focus on all the Ops activities which are this team/application specific while all centralized Ops activities will be taken by horizontal Ops team
61
Team structure model 3: Pure DevOps
Embedded team can be created by hiring people with blended skills or cross-training/on the job learning by Dev & Ops teams for each other's skills Team has single backlog with both Dev & Ops tasks Each team member is capable of selecting any item & work on it
62
Team structure model 3: Pure DevOps
Embedded team can be created by hiring people with blended skills or cross-training/on the job learning by Dev & Ops teams for each other's skills Team has single backlog with both Dev & Ops tasks Each team member is capable of selecting any item & work on it
63
Product owner DevOps responsibility
* Aligning Operations & Dev on business goal and vision
* Ensure operations needs are considered as input to requirement prioritization
* Maintain product backlog
64
Release manager
* Release management
* Define & maintain release plans which includes release content, dates & success criteria
* Manage release dependencies across applications/ product components
* Focus on coordinating with product owners, scrum masters & Ops stakeholders
* Define release types, associated workflows & approval requirement for release deployment
* Facilitate change management
* Ensure deployment automation/ continuous delivery setup
65
Scrum Master DevOps responsibility
* Ensure impediment free execution by Dev and Operations team
* Ensure adoption of agile practices
* Facilitate cross-functional training as well as team rotation
66
Process Model 1: Dev and Ops separate
* Dev in Scrum and Ops in any iterative model Governance team (Program Manager) for conflict resolution
* Few team members cross-participate in daily standups
* Frequent conflicts and less appreciation for each other's work Cross skilling of talents not possible
67
Process Model 2: Dev and Ops separate but following similar process
* Each group does a different agile approach
* Two different product backlogs
* Dev team works on user stories and Ops works on high priority
* Inter-dependent work items are prioritized by PO to resolve dependencies on time
* Cross skilling limited
68
Process Model 3: Unified process
* Single Product Owner with Product backlog Based on history, planned vs unplanned considered across Team works on prioritized user stories
* High priority is set for unplanned high severity incident, a team member having expertise in that takes up and resolves
* Cross skilling of talents is possible
69
DevOps metrics
* Number of build failures
* Total time taken for the build
* Unit test coverage
* Unit test success rate
* Rule compliance/violations
* Code complexity
* Duplicate lines of codes
* Percentage of API documented
70
Number of build failures
* Qualitative analysis of CI process output
* Help plan improvements to increase build success %
71
Total time taken for the build
* Track build processing time which includes compilation, inspecting, testing and deployment
* Helps in making builds more efficient for faster execution & early feedback
72
Unit test coverage and Unit test success rate
* Track efficiency of test driven development
* Helps ensure code quality
73
Rule compliance/violations Code Complexity Duplicate lines of codes
* Track non-compliance against set coding conventions
* Helps developers write better quality code
74
Percentage of API documented
* Track code documentation compliance
* Helps developers provide better understanding of code
75
Deploys / Day
* Total # of deployments / # of days
* Focus Area: Release frequency
* To understand increased collaboration & keep a track of time based improvement
76
Releases / Week
* Total # of releases / week (by environments)
* Focus Area: Release frequency
* Improvement in production release agility over time
77
Change lead time
* Time required to release a change in production from the time the development begins on the change request/ development is complete
* Focus Area: Agility
* To know the trend in lead time & help remove any bottlenecks if a degradation is observed
78
Code Coverage
* % of code covered through the test cycle (Unit/Regression test)
* Focus Area: Quality
* To know the testing effectiveness through the developed code
79
Release Efficiency/ repeatability
* % of successful releases over a period of time
* Focus Area: Quality
* Helps measure effectiveness of CD setup & observe trend over a period of time
80
Production defect Matrix
* Average # of defects released into production
* Focus Area: Quality
* Helps measure effectiveness of quality control through continuous delivery setup
81
Lead time provisioning
* Time taken for provisioning
* Focus Area: Quality
* To know the trend in lead time & help remove any bottlenecks if a degradation is observed
82
Availability
% availability of servers
Focus Area: Performance
Determine stability of environments across the enterprise
83
Outage
* Outage per day / week / month
* Focus Area: Performance
* To measure availability against SLA
84
Capacity
* % capacity availability & utilization
* Focus Area: Performance
* Gauge adequate capacity planning & use
85
Mean Time to recover
* Time required to recover from outages
* Focus Area: Reliability
* Improvement in MTTR over the time
86
Cost or effort per release
* Initial effort/cost per release compared to post DevOps
* Focus Area: Efficiency
* To understand how efficient release process is
87
Business -- IT interface road map
Business ownership is expanding from Dev to Ops activities (single PO) -\> Progressive demand management -\> Delayed scope definition -\> More involvement of all the teams -\> Frequent interaction and communication between the teams
88
HR road map
Define new roles and responsibilities -\> Define performance evaluation and reward policies Align HR policies
89
Organization road map
Organization structure changes to encourage unified Dev and Ops teams -\> Organization quality process and metrics updates -\> Vendor management Budgeting/funding, contract management is different -\> Governance changes due to unification of teams
90
Infrastructure road map
Technologies suitable for automation ALM and engineering tools procurement -\> Automation roadmaps and skill building
91
Leadership road map
Transformation buy-in -\> Encouraging cultural and mindset changes -\> Ensuring timely decision making on project scope and priorities
92
Traditional speed
When organization flows waterfall or related models, it is called traditional speed
93
Multi speed
When organization applies different levers and speeds for different projects, it is called multi speed IT
94
High speed
DevOps adoption is the way to increase the speed of deployment to production.
95
Principles of Lean
* Value - as defined by the customer
* Value Stream - comprised of all tasks and activities needed to create the value
* Flow - activities should be performed with minimal interruptions
* Pull - provide what the customer wants when they want it
* Perfection - doing things right the first time
