1
Q
What is the focus of enterprise computing?
A
- Implementing lean product evolution
- Using agile software production
- Managing the full lifecycle of software systems
The lifecycle is split into three core activities: Exploration, Development, and Operations.
2
Q
What are the three core activities in the lifecycle of enterprise computing?
A
- Exploration
- Development
- Operations
These activities form the backbone of the module.
3
Q
True or false: Enterprise computing is only about writing code.
A
FALSE
It involves building software that evolves over time and delivering value quickly and repeatedly.
4
Q
What is the goal of lean product evolution?
A
- Build the right thing
- Improve it continuously
- Avoid waste (time, effort, unnecessary features)
This approach emphasizes delivering value quickly and repeatedly.
5
Q
What are the key characteristics of the Waterfall model?
A
- Activities happen sequentially
- Each phase must finish before the next begins
- Very little feedback between stages
Problems include late discovery of mistakes and hard adaptation to changing requirements.
6
Q
What does the iterative model allow for in software development?
A
- Feedback loops between Exploration, Development, and Operations
- Learning from later stages feeds back into earlier stages
This model supports continuous improvement and rapid learning.
7
Q
What is the focus of Exploration in the software lifecycle?
A
- Understanding what to build
- Learning from users and stakeholders
- Reducing uncertainty early
It enables lean cycle evolution through build, measure, learn.
8
Q
What is the enabler for Development in the software lifecycle?
A
Version control
It enables collaboration, tracking changes, and automation.
9
Q
What are the key practices in Development?
A
- Continuous Integration (CI)
- Continuous Delivery (CD)
These practices ensure software is always in a releasable state.
10
Q
What does Operations focus on in the software lifecycle?
A
- Running software in production
- Keeping systems reliable
- Responding to failures
It is enabled by cloud computing.
11
Q
What are the key approaches in Operations?
A
- DevOps
- Site Reliability Engineering (SRE)
Both aim to bridge the gap between development and operations.
12
Q
What is the structure of the Assessment for this module?
A
- Examination (60%)
- Continuous Assessment (40%)
The examination covers Exploration, Development, and Operations, while continuous assessment focuses on Microservices.
13
Q
Fill in the blank: Enterprise Computing = managing software across its entire _______.
A
lifecycle
The three core activities are Exploration, Development, and Operations.
14
Q
What are the three activities in the software production process?
A
- Exploration
- Development
- Operations
Exploration focuses on deciding what and why to build.
15
Q
What does ‘Start With Why’ mean?
A
- Successful people and organisations begin with purpose
- Driven by beliefs, not just products or outcomes
It explores why some people succeed despite fewer resources and why motivation matters more than tools or funding.
16
Q
Who were the Wright Brothers?
A
- Orville and Wilbur Wright
- No college education
- Self-funded via a bicycle shop
They achieved sustained, powered flight on December 17th, 1903.
17
Q
What was the key difference between Langley and the Wright Brothers?
A
- Langley started with WHAT
- Wright brothers started with WHY
Langley was motivated by fame, while the Wright brothers were motivated by changing how people travel.
18
Q
What are the three layers of The Golden Circle?
A
- WHY – purpose, belief, cause
- HOW – process, values, approach
- WHAT – product or service
Inspirational organisations communicate WHY → HOW → WHAT.
19
Q
True or false: Starting with WHY inspires people to trust you.
A
TRUE
It also encourages loyalty and followers.
20
Q
What did Apple emphasize in their iPod advertising?
A
- 1,000 songs in your pocket
- Not about technical specs
- About why the product mattered
This creates an emotional connection.
21
Q
What is the key idea regarding customer and employee loyalty?
A
- Loyalty comes from shared values
- Not just price, features, or quality
People are attracted to organisations that believe what they believe.
22
Q
What do good decisions require?
A
- Information
- Data
- Advice
Examples include reading books, attending conferences, and talking to colleagues.
23
Q
What are the limits of data alone in decision making?
A
- Predicting outcomes perfectly is difficult
- Making repeatable ‘correct’ decisions is challenging
Purpose (WHY) provides guidance when certainty is impossible.
24
Q
What does the lecture summarize about successful people and organisations?
A
- Start with WHY
- Driven by beliefs, not rewards
Purpose sustains effort through uncertainty.
25
What is a **monolithic system**?
* A single program
* Runs as a single process
* Built from multiple modules
* Modules communicate via procedure calls
## Footnote
Everything runs together as one deployable unit.
26
List the reasons why **monoliths** are easy to develop.
* All code is in one place
* All code is in one language
* Developers can use existing skills
* Familiar tools and years of experience
## Footnote
This makes early development fast, straightforward, and low cognitive overhead.
27
How is **testing** simplified in monolithic systems?
* Whole system is built as one executable
* Automated test suites run against a single system instance
* Only one codebase to inspect if a test fails
## Footnote
Full debugging and monitoring tools are available, making testing complexity low compared to distributed systems.
28
What is **vertical scaling** in the context of monolithic systems?
* Replacing the current machine with a more powerful machine
* Faster CPU
* More memory
* Better hardware
## Footnote
Key limitation: there is a physical limit to how powerful a single machine can be.
29
What are the advantages of using a **centralised database** in monolithic systems?
* Easy to maintain accuracy
* Easy to maintain completeness
* Easy to maintain consistency of data
## Footnote
All modules read from and write to the same database, simplifying data management.
30
What does a **transaction** represent in a database?
* A unit of work
* Either commits (completes successfully) or aborts (fails)
## Footnote
There is no in-between state.
31
What are the **ACID properties** in monolithic systems?
* Atomicity
* Consistency
* Isolation
* Durability
## Footnote
These properties guarantee reliable database behaviour.
32
Define **atomicity** in the context of transactions.
* A transaction either succeeds completely or fails completely
## Footnote
Partial updates are never visible, even if the system crashes or errors occur.
33
What does **consistency** mean for a database after a transaction?
* Starts in a valid state
* Ends in another valid state
* Must respect integrity constraints and business rules
## Footnote
Transactions must ensure that the database remains valid.
34
What is the meaning of **isolation** in transactions?
* Concurrent transactions do not interfere with each other
## Footnote
This avoids race conditions, dirty reads, and inconsistent results.
35
Explain **durability** in the context of transactions.
* Once a transaction commits, its effects persist permanently
## Footnote
Committed data is not lost, even if the system crashes or power is lost.
36
Why do **ACID properties** work well for monoliths?
* Single process
* Single database
* No network communication between components
## Footnote
This makes monoliths reliable, predictable, and easier to reason about.
37
What are the recommended books for further reading on monoliths and microservices?
* Building Microservices – Sam Newman (2nd Edition)
* Monolith to Microservices – Sam Newman
## Footnote
These explain the strengths of monoliths and when and how systems evolve beyond them.
38
A monolith is a **single deployable system** that is easy to develop, test, and debug. It scales using _______.
vertical scaling
## Footnote
It uses a centralised database and relies on ACID transactions.
39
True or false: Monolithic systems are excellent for early systems and smaller teams, but limitations become clear at scale.
TRUE
## Footnote
This is a key consideration when evaluating the use of monolithic architectures.
40
What is the main focus when building a monolithic MVP?
* Planning for change
* Avoiding over-engineering
* How team structure affects system design
* Learning from real usage
## Footnote
These ideas are based on well-known observations in software engineering.
41
Who proposed the idea of **'Plan to Throw One Away'**?
Fred Brooks
## Footnote
This concept suggests that the first version of a system is often a learning exercise and may be poorly structured.
42
According to Fred Brooks, the first version of a system is often based on incorrect assumptions about __________.
Requirements, Scale, User behaviour
## Footnote
These factors contribute to the need for planning to discard the initial version.
43
What are the benefits of a **monolithic MVP** according to the lecture?
* Quick to build
* Easy to change
* Cheap to experiment with
## Footnote
The MVP is meant for learning, not perfection.
44
What does **Gall’s Law** state about complex systems?
A complex system that works is invariably found to have evolved from a simple system that worked
## Footnote
This implies that complexity must emerge gradually.
45
What should teams start with when building a **monolithic MVP**?
* A simple monolith
* Minimal features
## Footnote
Complexity should only be added when real requirements demand it.
46
What does **YAGNI** stand for?
You Aren’t Gonna Need It
## Footnote
This principle advises against implementing functionality until it is actually needed.
47
What are the consequences of adding features 'just in case' as per the **YAGNI** principle?
* Unused code
* Increased complexity
* Harder maintenance
## Footnote
These issues arise from speculative feature implementation.
48
According to **Conway’s Law**, how does team structure influence system design?
* Team structure influences architecture
* Teams split by function lead to tightly coupled monoliths
* Teams split by services lead to service-oriented systems
## Footnote
This reflects how organizational communication shapes system design.
49
What is the benefit of **'Eating Your Own Dogfood'**?
* Exposes real problems early
* Improves product quality
* Builds empathy with users
## Footnote
Internal use of products accelerates learning and improvement.
50
What are the overall principles that support starting with a **monolithic MVP**?
* Simplicity
* Learning through use
* Incremental evolution
* Avoiding premature optimisation
## Footnote
These principles advocate for delaying distributed complexity.
51
Fill in the blank: **Plan to throw one away** means that MVPs are __________.
disposable learning tools
## Footnote
This emphasizes the temporary nature of the initial system.
52
True or false: According to Gall's Law, complex systems must evolve from simple ones.
TRUE
## Footnote
This principle highlights the importance of gradual complexity in system design.
53
What does the principle of **Dogfooding** encourage teams to do?
Use the MVP themselves
## Footnote
This practice leads to faster feedback and better prioritization.
54
A **microservices system** consists of what?
* Multiple programs
* Multiple processes
* Communicates by sending messages over a network
## Footnote
Key contrast with monoliths: Monolith → one process; Microservices → many independent processes.
55
Each **microservice** is characterized by what features?
* Independently deployable
* Focuses on a single responsibility
## Footnote
This allows for better management and scaling of services.
56
Microservices communicate using what type of protocols?
* Network protocols
## Footnote
The most common protocol is Representational State Transfer (REST) built on HTTP.
57
What are the characteristics of **REST**?
* Stateless
* Resource-oriented
* Widely used due to simplicity and compatibility
## Footnote
REST treats microservices as resources accessed via HTTP methods.
58
List the **four REST resource archetypes** provided by microservices.
* Document
* Controller
* Collection
* Store
## Footnote
Each archetype serves different purposes and operations.
59
What operations are associated with the **Document** archetype?
* GET → read the resource
* PUT → update the resource
* DELETE → delete the resource
## Footnote
Used for file-like resources.
60
What operation is associated with the **Controller** archetype?
* POST → causes the resource to perform a task
## Footnote
This archetype is used for external or active resources.
61
What operations are associated with the **Collection** archetype?
* GET → list resources in the directory
* POST → create a new resource with an invented name
## Footnote
Used for directory-like resources.
62
What is the primary method for **scaling microservices**?
Horizontal scaling
## Footnote
This involves adding more machines, each capable of running one or many microservice instances.
63
What are the benefits of **reliability** in microservices?
* If one instance fails, others continue running
* Failures are isolated to individual services
## Footnote
However, network communication introduces new failure modes.
64
What does migrating from a **monolithic MVP** to microservices involve?
* Gradual
* Incremental
* Not a 'big bang' rewrite
## Footnote
Reasons include scaling limitations, team growth, and the need for independent deployment.
65
In microservices, each microservice typically owns its own what?
Database
## Footnote
This leads to distributed databases, which can cause issues with accuracy, completeness, and consistency of data.
66
What is a **distributed transaction**?
* Spans multiple databases
* Managed by multiple microservices
## Footnote
Two main approaches to handle distributed transactions are Two-phase commit and Sagas.
67
Describe the **Two-Phase Commit (2PC)** process.
* Phase 1 – Vote: Coordinator asks participants if they are prepared to commit
* Phase 2 – Decision: If all vote commit, coordinator tells all to commit; if any vote abort, tells all to abort
## Footnote
Properties include atomicity, strong consistency, blocking, poor scalability, and fragility under failures.
68
What are the key properties of **Sagas**?
* Atomicity is sacrificed
* System relies on eventual consistency
* More scalable and fault-tolerant than 2PC
## Footnote
Each participant commits or aborts immediately and releases locks immediately.
69
Compare **Two-Phase Commit** and **Sagas**.
* 2PC: Strong consistency, atomic, blocking, hard to scale
* Sagas: Eventual consistency, no global locks, better scalability, more complex logic
## Footnote
This highlights the trade-offs between the two approaches.
70
What are the **key takeaways** from the lecture on microservices?
* Microservices are multiple programs and processes communicating over a network
* REST over HTTP is commonly used
* Horizontal scaling is natural and flexible
* Reliability improves through redundancy
* Data is distributed, not centralized
* Distributed transactions are complex
* Two-phase commit ensures atomicity but scales poorly
* Sagas trade atomicity for scalability and resilience
## Footnote
These points summarize the essential concepts discussed in the lecture.
71
What are the **common organisational and architectural pitfalls** in microservices?
* Over-engineering
* Excessive abstraction
* Unnecessary complexity
## Footnote
These pitfalls can arise during the migration from a monolithic MVP to microservices.
72
Who described the **second-system effect**?
Fred Brooks
## Footnote
He is the author of *The Mythical Man-Month*.
73
What does the **second-system effect** lead to?
* Over-engineering
* Excessive abstraction
* Unnecessary complexity
## Footnote
It occurs when teams add too many features and complexity after learning from their first system.
74
What is the **key takeaway** regarding microservices evolution?
* Microservices should evolve gradually
* Avoid designing the 'perfect' system upfront
## Footnote
This approach helps mitigate risks associated with over-complication.
75
What is the meaning of **two-pizza teams** proposed by Jeff Bezos?
* Small teams communicate better
* Fewer coordination costs
* Clear ownership and accountability
## Footnote
A team should be small enough to be fed by two pizzas.
76
What is a **Big Ball of Mud**?
* Lacks clear architecture
* Grows through ad-hoc changes
* Becomes tightly coupled and messy
## Footnote
This term describes a system that has deteriorated due to short-term fixes and lack of refactoring.
77
What does **technical debt** refer to?
* Quick solutions today
* Extra cost tomorrow
## Footnote
It is a metaphor similar to financial debt, indicating that shortcuts can lead to future complications.
78
What are the **types of technical debt**?
* Code quality issues
* Architectural shortcuts
* Outdated dependencies
* Poor documentation
## Footnote
These issues can accumulate and create challenges in maintenance and development.
79
What does the **CAP theorem** state?
* A distributed system cannot simultaneously guarantee:
- Consistency (C)
- Availability (A)
- Partition Tolerance (P)
## Footnote
You can only fully guarantee two out of three.
80
What is the **Strangler Design Pattern**?
* Gradually replace parts of a system
* Keep the monolith running
* Identify a small piece of functionality to replace
## Footnote
This pattern allows for safer migration without a complete rewrite.
81
What are the **four main capabilities** of a modern version control system?
* Change Management
* Branch Management
* Build Management
* Collaboration
## Footnote
These capabilities support enterprise development and microservices.
82
Define **Change Management** in the context of version control.
* Retrieve any previous version of a file
* Track history of changes
* Enables rollback and auditing
## Footnote
Think of version control as time travel for code.
83
What does **Branch Management** allow in version control?
* Combine different development work streams
* Detect merge conflicts
* Supports parallel development
## Footnote
Branches allow teams to work on features without breaking the main system.
84
What is the role of **Build Management** in version control?
* Automate build scripts
* Enable continuous integration
* Reduce manual deployment work
## Footnote
This helps streamline the development process.
85
What does **Collaboration** enable in version control systems?
* Teams can work together across locations and time zones
* Shared repositories coordinate development
## Footnote
This enhances teamwork and efficiency.
86
What are the two main types of **repository organisation**?
* Monorepo
* Multirepo
## Footnote
These structures determine how code is organized and managed.
87
Define **Monorepo**.
* One large repository contains all microservices
* A commit can trigger builds across multiple services
## Footnote
This structure allows for atomic changes across services.
88
What are the **advantages** of a Monorepo?
* All code visible together
* Atomic changes across multiple services
* Easy sharing of libraries
## Footnote
This promotes better collaboration and visibility.
89
What are the **disadvantages** of a Monorepo?
* Requires strong ownership rules
* Harder to know what needs redeployment
## Footnote
These challenges can complicate management.
90
Define **Multirepo**.
* Each service has its own repository
* Commits trigger builds only for that service
## Footnote
This structure allows for clearer service ownership.
91
What are the **advantages** of a Multirepo?
* Clear service ownership
* Easier deployment decisions
* Smaller repos
## Footnote
This can simplify management and deployment.
92
What are the **disadvantages** of a Multirepo?
* Harder to make atomic changes across services
* Harder to see the whole system
* Library sharing becomes more complex
## Footnote
These issues can complicate integration.
93
What are the two common **branching strategies**?
* Feature-based development
* Trunk-based development
## Footnote
These strategies influence how development is organized.
94
Describe **Feature-Based Development**.
* Developers create branches for features
* Branches may last weeks or months
* Eventually merged into main branch
## Footnote
This allows for independent development.
95
What are the **advantages** of Feature-Based Development?
* Independent development
* Control over merge timing
## Footnote
This can enhance flexibility in development.
96
What are the **disadvantages** of Feature-Based Development?
* Merge conflicts increase
* Risk of integration hell
* Requires experience to manage
## Footnote
Integration hell occurs when merging becomes difficult due to divergence.
97
Describe **Trunk-Based Development**.
* Developers work mainly on one main branch (“trunk”)
* Short-lived branches merged quickly
* Frequent integration
## Footnote
This strategy promotes stability and quick integration.
98
What are the **advantages** of Trunk-Based Development?
* Avoids integration hell
* Main branch stays production-ready
## Footnote
This ensures that the codebase is always in a deployable state.
99
What are the **disadvantages** of Trunk-Based Development?
* Main branch changes constantly (“churn”)
* Requires strong testing discipline
## Footnote
This can lead to challenges in maintaining code quality.
100
What is a real-world example of **monorepo usage** at Google?
* ~1 billion files
* ~35 million commits
* ~86 TB repository size
* ~2 billion lines of code
## Footnote
This illustrates the scalability of monorepos with proper tooling.
101
What is the **memory hook** for version control?
Version control = time machine
## Footnote
This analogy helps remember the core function of version control systems.
102
What is the **main goal** of using version control in software teams?
Keep the main build stable, reliable, and always releasable
## Footnote
This goal emphasizes the importance of maintaining a functioning codebase in collaborative environments.
103
List the **seven core practices** of version control introduced in the lecture.
* Run commit tests locally
* Wait for commit tests
* Avoid commits on a broken build
* Never go home on a broken build
* Be prepared to revert
* Avoid commenting out tests
* Take responsibility for breakages
## Footnote
These practices are derived from continuous delivery principles.
104
What does it mean to **run commit tests locally**?
* Update your local project from version control
* Run tests locally
* Make sure your changes build successfully
## Footnote
This practice helps prevent breaking the shared codebase and catches problems early.
105
Why is it important to **wait for commit tests** to complete?
* Confirms the system still works after integration
* Prevents unnoticed breakages spreading
## Footnote
A commit isn’t considered “done” until tests pass.
106
True or false: You should **commit changes** even if the main build is broken.
FALSE
## Footnote
New commits during a broken build complicate debugging and can hide the original cause of failures.
107
What should you do if the build is failing before you leave work?
Do not go home
## Footnote
Leaving with a broken build can block other developers and slow down the entire team.
108
What does it mean to **be prepared to revert**?
* Reverting a commit completely may be the best fix
## Footnote
This approach is faster than debugging complex failures and helps restore system stability quickly.
109
Why should you **avoid commenting out tests**?
* Tests protect system quality
* Removing them hides real problems
* Leads to unstable releases
## Footnote
The correct approach is to fix the code, not the tests.
110
What does it mean to **take responsibility for breakages**?
* Help fix the build if your commit breaks something
## Footnote
Integration failures are shared problems, encouraging collaboration and accountability.
111
What is the core philosophy of **Continuous Delivery**?
* Keep software always releasable
* Automate builds and testing
* Maintain a stable main branch
## Footnote
These principles support the overall goal of reliable software development.
112
List the **essential behaviours** for version control.
* Test locally before committing
* Monitor builds after committing
* Never add changes to a broken build
* Fix problems immediately
* Revert when necessary
* Keep tests active
* Take responsibility for failures
## Footnote
These behaviours are crucial for maintaining a stable, working system.
113
Fill in the blank: **Test locally first**, watch the build, and **________** on a broken build.
STOP committing
## Footnote
This highlights the importance of not introducing new changes when the build is unstable.
114
What is the **ADHD-Friendly Memory Hook** for reverting?
Revert fast, don’t panic
## Footnote
This encourages quick action to restore stability without stress.
115
What is the main idea of **Continuous Integration (CI)**?
Integrate code frequently and automatically so the system is always in a releasable state.
## Footnote
CI emphasizes the importance of maintaining a releasable state through frequent integration.
116
Define **Continuous Integration (CI)**.
The practice of quickly integrating newly developed code with the rest of the application code to be released.
## Footnote
This process is usually automated and produces a build artifact.
117
What are the **four release stages** in traditional product delivery?
* Alpha release
* Beta release
* Release candidate
* Final release
## Footnote
Traditional delivery often resulted in long delays and risky big releases.
118
What are the **three environments** used in modern feature delivery?
* Development
* Staging
* Production
## Footnote
Changes move continuously through these environments instead of large releases.
119
What is the purpose of the **Development Environment (Dev)**?
* Combine work from one team
* Run unit tests
* Catch early issues
## Footnote
Updated continuously during a two-week sprint.
120
What is the purpose of the **Staging Environment**?
* Integration across teams
* Run service-level tests
* Validate multi-service behaviour
## Footnote
Looks like production and is updated at the end of every two-week sprint.
121
What is the purpose of the **Production Environment**?
* Deliver value
* Maintain reliability
## Footnote
Used by real customers and updated when business decides it’s appropriate.
122
What can modern version control systems support in terms of **build management**?
* Script build activities
* Automate compilation
* Run automated tests
* Generate build artifacts
## Footnote
This is central to Continuous Integration.
123
What does a **git push** do?
Uploads local changes to a remote repository.
## Footnote
Used when you are ready to integrate changes.
124
What is a **git pull request**?
Proposes changes for integration into the main branch and allows review before merging.
## Footnote
Important for collaboration, code review, and quality control.
125
What are the layers of the **Test Pyramid**?
* Unit tests (bottom)
* Service tests (middle)
* End-to-end tests (top)
## Footnote
The pyramid visualizes the number of tests at each layer.
126
What is the purpose of **Unit Tests**?
* Fast feedback
* Catch logic errors early
## Footnote
Run small modules in isolation and are executed quickly.
127
What is the purpose of **Service Tests**?
* Ensure services interact correctly
* Test service boundaries
## Footnote
Run hundreds of tests and stub out collaborating services.
128
What is the purpose of **End-to-End Tests**?
* Test the whole system working together
## Footnote
Mimic real user behaviour and run in several minutes.
129
What does the term **integration test** refer to?
Can mean testing some modules together (partial test) or testing the entire system together (full end-to-end test).
## Footnote
Always clarify which meaning is intended.
130
Define a **stub**.
A stand-in for real code that produces predefined responses.
## Footnote
Used in service testing to avoid calling real services.
131
Define a **mock**.
A stub plus assertions that checks call order and number of calls made.
## Footnote
Mocks test interaction behaviour, not just output.
132
What is a **brittle test**?
Fails because another service fails.
## Footnote
This occurs when a test depends too much on external systems.
133
What is a **flaky test**?
Sometimes fails, often due to timeouts, race conditions, or network delays.
## Footnote
Flaky tests reduce trust in the testing system and are dangerous for CI.
134
List the **best practices for Continuous Integration**.
* Integrate frequently
* Automate builds
* Automate testing
* Keep main branch releasable
* Fix broken builds immediately
* Avoid flaky tests
* Maintain fast feedback loops
## Footnote
Inspired by David Farley.
135
Name two key books on **Continuous Integration**.
* Continuous Delivery – Humble & Farley
* Building Microservices – Sam Newman
## Footnote
These books expand on build automation, testing strategies, and deployment pipelines.
136
What is the main principle of **Continuous Integration**?
Small, frequent, automated changes reduce risk.
## Footnote
This principle underlies the entire CI process.
137
What does **CI** stand for?
Continuous Integration
## Footnote
Emphasizes integrating early and often.
138
Fill in the blank: The **Test Pyramid** structure consists of many unit tests, fewer service tests, and _______ end-to-end tests.
few
## Footnote
This structure helps prioritize testing efforts.
139
Fill in the blank: A **stub** is a fake response, while a **mock** is a fake plus _______.
behaviour check
## Footnote
This distinction is important in testing.
140
Fill in the blank: A **brittle test** always fails due to _______.
others
## Footnote
This indicates a lack of isolation in testing.
141
Fill in the blank: A **flaky test** sometimes fails due to _______.
timeouts, race conditions, or network delays
## Footnote
Flaky tests can undermine confidence in the CI process.
142
What is the main idea of **Continuous Integration**?
Requires the right testing culture and team behaviours
## Footnote
Continuous Integration is not just automation.
143
What does **Shift-Left Testing** mean?
* Move testing earlier in the development process
* Test while coding
* Test before merging
* Test before deploying
## Footnote
Testing moves left on the timeline.
144
Why is **Shift-Left Testing** important for Continuous Integration?
* Code is integrated frequently
* Early testing prevents broken builds
* Bugs are cheaper to fix early
## Footnote
Detect problems before they reach staging or production.
145
What happens **without Shift-Left Testing**?
* Bugs accumulate
* CI builds fail often
* Developers lose trust in the pipeline
## Footnote
These issues can lead to significant delays and quality degradation.
146
What is the **Test-Driven Development (TDD)** cycle?
* Write a failing test
* Make the test pass
* Refactor the code
## Footnote
This cycle is often called Red → Green → Refactor.
147
How does **TDD support Continuous Integration**?
* Produces many small unit tests
* Encourages safe refactoring
* Keeps builds stable
* Works perfectly with automated pipelines
## Footnote
TDD naturally supports shift-left testing.
148
What is the **Test Snow Cone**?
* Too many end-to-end tests
* Few unit tests
## Footnote
It is the opposite of the test pyramid.
149
Why is the **Test Snow Cone** bad for Continuous Integration?
* End-to-end tests are slow
* End-to-end tests are fragile
* End-to-end tests are hard to debug
## Footnote
If most tests are end-to-end, builds become slow and failures are unclear.
150
What is the **correct approach** to testing in Continuous Integration?
* Many fast unit tests
* Moderate service tests
* Few end-to-end tests
## Footnote
Follow the test pyramid.
151
What does the **Normalisation of Deviance** refer to?
* Small rule violations become normal over time
## Footnote
Examples include ignoring flaky tests or accepting broken builds.
152
Why is the **Normalisation of Deviance** dangerous?
* Build failures become routine
* Trust in CI disappears
* Quality degrades slowly but steadily
## Footnote
A broken build must always be treated as urgent.
153
What are **Build Light Indicators**?
* Visual indicators showing build status
* Examples: Green = build passing, Red = build failing
## Footnote
They make build status visible to everyone.
154
What is the purpose of **Build Light Indicators**?
* Makes build status visible to everyone
* Encourages shared responsibility
* Immediate awareness of failures
## Footnote
Goal: Make CI status impossible to ignore.
155
What are **Dedicated Test Teams**?
* A separate team responsible for testing
## Footnote
Traditional model has developers writing code and testers testing later.
156
What are the problems with **Dedicated Test Teams** in a CI context?
* Slow feedback loops
* Separate ownership
* Reduce shared responsibility
* Delay integration
## Footnote
This conflicts with shift-left and continuous integration.
157
What is the **modern view** on testing in Continuous Integration?
* Testing should be embedded within development teams
* Automated
* Everyone’s responsibility
## Footnote
Developers must write tests, maintain test quality, and fix broken builds.
158
What is the key reading for understanding CI practices?
Sam Newman, Building Microservices (Chapter 8)
## Footnote
Covers CI practices, testing strategies, and team ownership.
159
What are the key points for **Continuous Integration success**?
* Testing early (shift-left)
* Writing tests before code (TDD)
* Avoiding too many slow tests (snow cone)
* Preventing acceptance of broken builds (normalisation of deviance)
* Making build status visible (build lights)
* Avoiding siloed test teams
## Footnote
CI is cultural and behavioural — not just technical.
160
What is the memory hook for **Shift Left**?
Test early
## Footnote
This emphasizes the importance of early testing in the development process.
161
What is the memory hook for **TDD**?
Red → Green → Refactor
## Footnote
This summarizes the TDD cycle.
162
What is the memory hook for the **Snow Cone**?
Too many slow tests
## Footnote
This highlights the issue with having excessive end-to-end tests.
163
What should never be normal in CI?
Broken build
## Footnote
A broken build must always be treated as urgent.
164
What is the goal regarding **build status**?
Make it visible
## Footnote
This encourages shared responsibility and immediate awareness of failures.
165
Who is responsible for testing in a modern CI environment?
Everyone
## Footnote
Testing is everyone's job in a CI context.
166
What matters as much as automation in CI?
Culture
## Footnote
CI success depends on both cultural and technical aspects.
Computer Science (Year 3)
flashcards
Decks in class (3)
# Cards
