The Addison Something

Date: 2022-01-27
| Asking experts to do boring and repetitive, and yet technically
| demanding tasks is the most certain way of ensuring human error
| that we can think of, short of sleep deprivation, or inebriation
Chapter: Chapter 1. The Problem of Delivering Software


Date: 2022-01-27
| Automating deployments frees your expensive, highly skilled,
| overworked staff to work on higher-value activities
Chapter: Chapter 1. The Problem of Delivering Software


Date: 2022-01-27
| Often, deployments fail because somebody patched the production
| environment last time they deployed, but the change was not recorded
Chapter: Chapter 1. The Problem of Delivering Software


Date: 2022-01-27
| If releases are frequent, the delta between releases will be
| small. This significantly reduces the risk associated with releasing
| and makes it much easier to roll back. Frequent releases also lead
| to faster feedback—indeed, they require it
Chapter: Chapter 1. The Problem of Delivering Software


Date: 2022-01-27
| A working software application can be usefully decomposed into
| four components: executable code, configuration, host environment,
| and data
Chapter: Chapter 1. The Problem of Delivering Software


Date: 2022-01-27
| If any of them changes, it can lead to a change in the behavior
| of the application. Therefore we need to keep all four of these
| components under control and ensure that a change in any one of
| them is verified.
Chapter: Chapter 1. The Problem of Delivering Software


Date: 2022-01-27
| The environments these tests run in must be as similar as possible
| to production, to verify that any changes to our environments have
| not affected the application’s ability to work
Chapter: Chapter 1. The Problem of Delivering Software


Date: 2022-01-27
| People take longer, they introduce errors, and they are not
| auditable. Moreover, performing manual build, test, and deployment
| processes is boring and repetitive—far from the best use of
| people. People are expensive and valuable, and they should be focused
| on producing software that delights its users and then delivering
| those delights as fast as possible—not on boring, errorprone tasks
| like regression testing, virtual server provisioning, and deployment,
| which are best done by machines.
Chapter: Chapter 1. The Problem of Delivering Software


Date: 2022-01-27
| It is essential that everybody involved in the process of delivering
| software is involved in the feedback process. That includes
| developers, testers, operations staff, database administrators,
| infrastructure specialists, and managers. If people in these roles do
| not work together on a day-to-day basis (although we recommend that
| teams should be cross-functional), it is essential that they meet
| frequently and work to improve the process of delivering software
Chapter: Chapter 1. The Problem of Delivering Software


Date: 2022-01-27
| A process based on continuous improvement is essential to the rapid
| delivery of quality software
Chapter: Chapter 1. The Problem of Delivering Software


Date: 2022-01-28
| is the build, deployment, and test process that we apply to that
| change that validates whether the change can be released
Chapter: Chapter 1. The Problem of Delivering Software


Date: 2022-01-28
| Every change must be evaluated for its fitness
Chapter: Chapter 1. The Problem of Delivering Software


Date: 2022-01-28
| In software, when something is painful, the way to reduce the pain
| is to do it more frequently, not less
Chapter: Chapter 1. The Problem of Delivering Software


Date: 2022-01-28
| Continuous integration detects any change that breaks the system or
| does not fulfill the customer’s acceptance criteria at the time
| it is introduced into the system. Teams then fix the problem as
| soon as it occurs (this is the first rule of continuous integration
Chapter: Chapter 1. The Problem of Delivering Software


Date: 2022-01-28
| Every change is, in effect, a release candidate. Every time a change
| is committed to version control, the expectation is that it will
| pass all of its tests, produce working code, and can be released into
| production. This is the starting assumption. The job of a continuous
| integration system is to disprove this assumption, to show that a
| particular release candidate is not fit to make it into production.
Chapter: Chapter 1. The Problem of Delivering Software


Date: 2022-01-28
| Ideally, everybody within an organization is aligned with its goals,
| and people work together to help each to meet them. Ultimately the
| team succeeds or fails as a team, not as individuals
Chapter: Chapter 1. The Problem of Delivering Software


Date: 2022-01-28
| When something goes wrong, people spend as much time blaming one
| another as they do fixing the defects that inevitably arise from
| such a siloed approach
Chapter: Chapter 1. The Problem of Delivering Software


Date: 2022-01-28
| The whole team should regularly gather together and hold a
| retrospective on the delivery process. This means that the team
| should reflect on what has gone well and what has gone badly,
| and discuss ideas on how to improve things
Chapter: Chapter 1. The Problem of Delivering Software


Date: 2022-01-28
| Deming cycle: plan, do, study, act
Chapter: Chapter 1. The Problem of Delivering Software


Date: 2022-01-29
| In our view, the stress associated with software releases and their
| manual, error-prone nature are related factors
Chapter: Chapter 1. The Problem of Delivering Software


Date: 2022-01-29
| Continuous integration represents a paradigm shift. Without
| continuous integration, your software is broken until somebody
| proves it works, usually during a testing or integration stage. With
| continuous integration, your software is proven to work (assuming
| a sufficiently comprehensive set of automated tests) with every
| new change
Chapter: Chapter 3. Continuous Integration


Date: 2022-01-29
| Continuous Integration on a Dollar a Day
Chapter: Chapter 3. Continuous Integration


Date: 2022-01-30
| Unit tests are written to test the behavior of small pieces of your
| application in isolation
Chapter: Chapter 3. Continuous Integration


Date: 2022-01-30
| Component tests test the behavior of several components of your
| application
Chapter: Chapter 3. Continuous Integration


Date: 2022-01-30
| Acceptance tests test that the application meets the acceptance
| criteria decided by the business, including both the functionality
| provided by the application and its characteristics such as capacity,
| availability, security, and so on
Chapter: Chapter 3. Continuous Integration


Date: 2022-01-30
| The fact is that the reverse is true: Every time a build fails,
| it indicates that a problem has been found that may otherwise have
| made it into production
Chapter: Chapter 3. Continuous Integration


Date: 2022-01-30
| checking in less than an hour before the end of work, and instead
| leave that to do first thing the next morning
Chapter: Chapter 3. Continuous Integration


Date: 2022-01-31
| Mary and Tom Poppendieck’s classic, Lean Software Development:
| An Agile Toolkit
Chapter: Chapter 5. Anatomy of the Deployment Pipeline


Date: 2022-01-31
| Figure 5.2 Changes moving through the deployment pipeline
Chapter: Chapter 5. Anatomy of the Deployment Pipeline


Date: 2022-01-31
| The commit stage asserts that the system works at the technical
| level. It compiles, passes a suite of (primarily unit-level)
| automated tests, and runs code analysis
Chapter: Chapter 5. Anatomy of the Deployment Pipeline


Date: 2022-01-31
| Automated acceptance test stages assert that the system works at
| the functional and nonfunctional level, that behaviorally it meets
| the needs of its users and the specifications of the customer
Chapter: Chapter 5. Anatomy of the Deployment Pipeline


Date: 2022-01-31
| Manual test stages assert that the system is usable and fulfills
| its requirements, detect any defects not caught by automated tests,
| and verify that it provides value to its users. These stages might
| typically include exploratory testing environments, integration
| environments, and UAT (user acceptance testing
Chapter: Chapter 5. Anatomy of the Deployment Pipeline


Date: 2022-01-31
| Release stage delivers the system to users, either as packaged
| software or by deploying it into a production or staging environment
| (a staging environment is a testing environment identical to the
| production environment
Chapter: Chapter 5. Anatomy of the Deployment Pipeline


Date: 2022-01-31
| When you deploy your application, you should have an automated
| script that does a smoke test to make sure that it is up and running
Chapter: Chapter 5. Anatomy of the Deployment Pipeline


Date: 2022-01-31
| Make will ensure that you only compile those source code files that
| have changed since the last time the build was run. This feature,
| known as an incremental build, can save hours over a clean build
| on large projects
Chapter: Chapter 6. Build and Deployment Scripting


Date: 2022-01-31
| Rake is a general-purpose build scripting tool. Of course,
| your development team will need to have (or acquire) some basic
| programming skills in Ruby, but you can say the same for Ant or NAnt
Chapter: Chapter 6. Build and Deployment Scripting


Date: 2022-01-31
| One of the core principles of environment management is that changes
| to testing and production environments should only be made through
| an automated process
Chapter: Chapter 6. Build and Deployment Scripting


Date: 2022-02-02
| We wrote a simple Ruby script that parsed the config.xml files
| and tried to connect to each URI in turn. It would then print the
| results on the console
Chapter: Chapter 6. Build and Deployment Scripting


Date: 2022-02-02
| If one of the goals of the deployment pipeline is to eliminate builds
| that are not fit to make it into production, then the commit stage is
| the bouncer at the door. Its aim is to ensure that any undesirables
| are rejected before they cause any trouble. The principal goal of
| the commit stage is to either create deployable artifacts, or fail
| fast and notify the team of the reason for the failure
Chapter: Chapter 7. The Commit Stage


Date: 2022-02-02
| Either a syntax error has been introduced into the code, caught by
| compilation in compiled languages
Chapter: Chapter 7. The Commit Stage


Date: 2022-02-02
| or a semantic error has been introduced into the application,
| causing one or more tests to fail
Chapter: Chapter 7. The Commit Stage


Date: 2022-02-02
| there is a problem with the configuration of the application or
| its environment (including the operating system
Chapter: Chapter 7. The Commit Stage


Date: 2022-02-02
| The latter is dependency injection. This is more flexible because now
| I can create Cars with different kinds of Engine without changing
| the Car code. I could even create my Car with a special TestEngine
| that only pretends to be an Engine while I’m testing the Car
Chapter: Chapter 7. The Commit Stage


Date: 2022-02-02
| Stubbing is the replacement of a part of a system with a simulated
| version that provides canned responses
Chapter: Chapter 7. The Commit Stage


Date: 2022-02-02
| Mocking is a newer technique. It is motivated by a liking for stubs,
| and a desire to use them widely, without incurring the work of
| writing lots of stub code. Wouldn’t it be wonderful if, instead
| of writing tedious code to stub out all the dependencies for the
| classes we are testing, we could just let the computer build some
| stubs for us automatically
Chapter: Chapter 7. The Commit Stage


Date: 2022-02-02
| Mocking allows you to effectively say, “Build me an object that
| can pretend to be a class of type X
Chapter: Chapter 7. The Commit Stage


Date: 2022-02-02
| Remember that computing power is cheap and people are expensive
Chapter: Chapter 7. The Commit Stage


Date: 2022-02-02
| The commit stage of your deployment pipeline should be run every
| time someone introduces a change into your application’s code
| or configuration
Chapter: Chapter 7. The Commit Stage


Date: 2022-02-03
| An automated process that takes the binaries created by your commit
| stage and deploys them into the environment
Chapter: Chapter 10. Deploying and Releasing Applications


Date: 2022-02-03
| This is one of the most powerful techniques we know for managing
| releases. The idea is to have two identical versions of your
| production environment, which we’ll call blue and green
Chapter: Chapter 10. Deploying and Releasing Applications


Date: 2022-02-03
| It is usually not possible to switch over directly from the green
| database to the blue database because it takes time to migrate the
| data from one release to the next if there are schema changes.
| One way to approach this problem is to put the application into
| read-only mode shortly before switchover. You can then take a copy of
| the green database, restore it into the blue database, perform the
| migration, and then switch over to the blue system. If everything
| checks out, you can put the application back into read-write mode
Chapter: Chapter 10. Deploying and Releasing Applications


Date: 2022-02-04
| Production environments should be completely locked down, so that
| only your deployment pipeline can make changes to it
Chapter: Chapter 10. Deploying and Releasing Applications


Date: 2022-01-31
| The ability to deploy the system at all stages of its development by
| pressing a button encourages its frequent use by testers, analysts,
| developers, and (most importantly) users
Chapter: Chapter 5. Anatomy of the Deployment Pipeline