Introduction To DevOps Flashcards

1
Q

DevOps adoption

A
  • People - Alignment of teams
  • Process - Alignment of process, Measurement & optimization
  • Technology - Alignment of capabilities, Tool stack & implementation
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

DevOps is…

A

A set of capabilities, across the IT Value Stream (PLAN – BUILD – RUN) which enhances throughput, quality and business value

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Minimum Dev Capabilities

A
  • Version Control
  • Static/Dynamic Code Quality Analysis
  • Build Automation
  • Baseline in Artifact Repository
  • Continuous Integration
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Minimum Test Capabilities

A

Functional/Acceptance test

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Minimum Infrastructure Capabilities

A
  • Database deployment
  • CD Automation
  • Release Management
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Minimum Ops Capabilities

A
  • Incident Management Tools
  • Monitoring and Dashboard
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Good to have Business Capabilities

A
  • Acceptance Testing
  • Rapid Prototyping
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Good to have Dev Capabilities

A
  • Code coverage
  • Code review
  • Unit testing
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Good to have Test Capabilities

A
  • Test and Defect Management
  • Test Data Management
  • Service Virtualization
  • Performance Testing
  • Security Testing
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Good to have Infrastructure Capabilities

A
  • Infrastructure Layer
  • Environment Management
  • Containerization
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Good to have Ops Capabilities

A

Support Analytics

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Policies/Procedure/Methods Business

A
  • Agile
  • Big Room Planning
  • Lean
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Policies/Procedure/Methods Dev

A
  • Agile
  • Feature Toggle
  • Incremental Design
  • Micro Services
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Policies/Procedure/Methods Testing

A

Progressive Test Automation

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Policies/Procedure/Methods Infrastructure

A
  • On demand/cloud based Infra
  • Infra-as-code
  • Just enough Infra
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Policies/Procedure/Methods Ops

A
  • Predictive Monitoring
  • Self Healing
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

Feature Toggle

A

Releasing features to a selected cohort to get their responses prior to release to entire user base

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

Incremental Design

A

Based on SOLID principles

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

SOLID

A
  • Single responsibility principle
  • Open closed principle
  • Liskov substitution principle
  • Interface segregation principle
  • Dependency inversion principle
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
Q

Microservices Components

A
  • Client-side user interface
  • Database Server side application
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
26
Q

Client-side user interface

A

Manages the views and the user interface of the application

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
27
Q

Database

A

Stores the data in a relational database

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
28
Q

Server side application

A

Handles HTTP requests and executes the domain logic, extracts and updates data from/to the database and provide the HTML views

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
29
Q

Single responsibility principle

A

A class should have only one reason to change

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
30
Q

Open closed principle

A

Software entities should be open for extension, but closed for modification

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
31
Q

Liskov substitution principle

A

Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
32
Q

Interface segregation principle

A

Clients should not be forced to depend upon interfaces that they do not use

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
33
Q

Dependency inversion principle

A

High-level modules should not depend on low-level modules. Both should depend on abstractions.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
34
Q

Continuous Integration Pipeline

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
35
Q

Progressive Automation

A

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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
36
Q

Continuous and automated testing

A

Involves using automated testing tools which can execute tests, provide outcomes of the tests in the form of reports and can be run repeatedly.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
37
Q

Service Virtualization

A

Helps in simulating application dependencies and begin testing earlier.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
38
Q

On-demand infrastructure

A

A model where computing resources are made available to the user as needed.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
39
Q

Infra-as-code

A

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
Q

Just enough infra

A

Involves provisioning infrastructure from a cloud or a virtual setup when and as much required.

41
Q

Continuous Deployment Automation

A

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
Q

Release Management

A

The automated tools for release management allow the integration of the management and execution of releases.

43
Q

Database deploy

A

The automated database deployment tools generate a single deployment script that contains the meta data and structure changes.

44
Q

Infrastructure layer and environment management

A

Managed by tools like Chef which help spinning of virtual machines, syncing them, help make changes across multiple servers etc.

45
Q

Containerization

A

Allows virtual machines to share a single host operating system and relevant binaries, drivers etc.

46
Q

Predictive Monitoring

A

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
Q

Self-healing

A

Involves making the system take decisions based on continuous checking and optimization of its state and adapt to changing conditions.

48
Q

Incident Management

A

Centralized incident management solutions avoids redundant alerts.

49
Q

Support Analytics

A

Tools for support analytics do a deep search for data, do centralized logging and parsing and display the data in a neat way.

50
Q

Monitoring Dashboard

A

A dashboard provides a complete view of the pipeline. The dashboard can be based on different perspectives.

51
Q

Principles for stack tools

A

Repeatability Reliability End to end automation 100% source control Auto build quality Done is released Continuous feedback Customer appetite for tooling

52
Q

Done is released:

A

Pipeline should ensure that “done-ness” as per definition of done is only released to production

53
Q

Continuous Integration steps

A
  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
Q

Continuous Delivery stesp

A
  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
Q

Application life cycle management(ALM) tool

A

Can be used for tracking and managing the user stories, team activities and ceremonies.

56
Q

Static and Dynamic code analysis

A

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
Q

Code Coverage

A

Check the coverage of the source code by the test cases. Help checks the quality of the test cases.

58
Q

Build automation

A

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
Q

Baseline in artifact/binary repository

A

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
Q

Team structure model 2: One team with Ops extension

A

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
Q

Team structure model 3: Pure DevOps

A

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
Q

Team structure model 3: Pure DevOps

A

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
Q

Product owner DevOps responsibility

A
  • Aligning Operations & Dev on business goal and vision
  • Ensure operations needs are considered as input to requirement prioritization
  • Maintain product backlog
64
Q

Release manager

A
  • 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
Q

Scrum Master DevOps responsibility

A
  • Ensure impediment free execution by Dev and Operations team
  • Ensure adoption of agile practices
  • Facilitate cross-functional training as well as team rotation
66
Q

Process Model 1: Dev and Ops separate

A
  • 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
Q

Process Model 2: Dev and Ops separate but following similar process

A
  • 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
Q

Process Model 3: Unified process

A
  • 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
Q

DevOps metrics

A
  • 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
Q

Number of build failures

A
  • Qualitative analysis of CI process output
  • Help plan improvements to increase build success %
71
Q

Total time taken for the build

A
  • Track build processing time which includes compilation, inspecting, testing and deployment
  • Helps in making builds more efficient for faster execution & early feedback
72
Q

Unit test coverage and Unit test success rate

A
  • Track efficiency of test driven development
  • Helps ensure code quality
73
Q

Rule compliance/violations Code Complexity Duplicate lines of codes

A
  • Track non-compliance against set coding conventions
  • Helps developers write better quality code
74
Q

Percentage of API documented

A
  • Track code documentation compliance
  • Helps developers provide better understanding of code
75
Q

Deploys / Day

A
  • Total # of deployments / # of days
  • Focus Area: Release frequency
  • To understand increased collaboration & keep a track of time based improvement
76
Q

Releases / Week

A
  • Total # of releases / week (by environments)
  • Focus Area: Release frequency
  • Improvement in production release agility over time
77
Q

Change lead time

A
  • 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
Q

Code Coverage

A
  • % of code covered through the test cycle (Unit/Regression test)
  • Focus Area: Quality
  • To know the testing effectiveness through the developed code
79
Q

Release Efficiency/ repeatability

A
  • % 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
Q

Production defect Matrix

A
  • Average # of defects released into production
  • Focus Area: Quality
  • Helps measure effectiveness of quality control through continuous delivery setup
81
Q

Lead time provisioning

A
  • Time taken for provisioning
  • Focus Area: Quality
  • To know the trend in lead time & help remove any bottlenecks if a degradation is observed
82
Q

Availability

A

% availability of servers

Focus Area: Performance

Determine stability of environments across the enterprise

83
Q

Outage

A
  • Outage per day / week / month
  • Focus Area: Performance
  • To measure availability against SLA
84
Q

Capacity

A
  • % capacity availability & utilization
  • Focus Area: Performance
  • Gauge adequate capacity planning & use
85
Q

Mean Time to recover

A
  • Time required to recover from outages
  • Focus Area: Reliability
  • Improvement in MTTR over the time
86
Q

Cost or effort per release

A
  • Initial effort/cost per release compared to post DevOps
  • Focus Area: Efficiency
  • To understand how efficient release process is
87
Q

Business – IT interface road map

A

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
Q

HR road map

A

Define new roles and responsibilities -> Define performance evaluation and reward policies Align HR policies

89
Q

Organization road map

A

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
Q

Infrastructure road map

A

Technologies suitable for automation ALM and engineering tools procurement -> Automation roadmaps and skill building

91
Q

Leadership road map

A

Transformation buy-in -> Encouraging cultural and mindset changes -> Ensuring timely decision making on project scope and priorities

92
Q

Traditional speed

A

When organization flows waterfall or related models, it is called traditional speed

93
Q

Multi speed

A

When organization applies different levers and speeds for different projects, it is called multi speed IT

94
Q

High speed

A

DevOps adoption is the way to increase the speed of deployment to production.

95
Q

Principles of Lean

A
  • 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