ryanlevell
commented
1 year ago Random notes, as I originally cherry-picked chapters to read:
55: "... most software developed by large teams spends a significant proportion of its development time in an unusable state. The reason for this is easy to understand: Nobody is interested in trying to run the whole application until it is finished. Developers check in changes and might even run automated unit tests, but nobody is trying to actually start the application and use it in a production-like environment."
"This is doubly true in projects that use long-lived branches or defer acceptance testing until the end. Many such projects schedule lengthy integration phases at the end of development to allow the development team time to get the branches merged and the application working so it can be acceptance-tested. Even worse, some projects find that when they get to this phase, their software is not fit for purpose. These integration periods can take an extremely long time, and worst of all, nobodv has any way to predict how long."
56: "Everything in your project must be checked in to a single version control repository: code, tests, database scripts, build and deployment scripts, and anything else needed to create, install, run, and test your application."
60: "Keep the Build and Test Process Short If it takes too long to build the code and run the unit tests, you will run into the following problems:
• People will stop doing a full build and running the tests before they check in. You will start to get more failing builds.
• The continuous integration process will take so long that multiple commits will have taken place by the time you can run the build again, so you won't know which check-in broke the build.
• People will check in less often because they have to sit around for ages waiting for the software to build and the tests to run."
61: "If you find that the second build takes longer than half an hour or so, you should consider running this test suite in parallel ..."
"It is often useful to incorporate a simple smoke test suite into your commit stage. This smoke test should perform a few simple acceptance and integration tests to make sure that the most commonly used functionality isn't broken-and report back quickly if it is."
62: "The first prerequisite to achieve this is careful configuration management, not just of source code, but also of test data, database scripts, build scripts, and deployment scripts. All of these must be stored in version control ..."
96: "Integration tests can be written in the same way as you write normal acceptance tests. Normally, integration tests should run in two contexts: firstly with the system under test running against the real external systems it depends on, or against their replicas controlled by the service provider, and secondly against a test harness which you create as part of your codebase."
*** How do IT and AT differ?
100: "Close collaboration between developers and testers throughout the development of a story is essential to a smooth path to the release. Whenever developers finish some functionality, they should call over the testers to review it. The testers should take over the developers' machine to do this testing. During this time, developers might continue work on an adjacent terminal or laptop, perhaps fixing some outstanding regression bugs. This way they're still occupied (since testing can take some time), but are easily available in case the tester needs to discuss anything."
"The problem is even worse when there are no acceptance tests or where acceptance tests are not effective because features are being developed on branches that are not merged regularly to trunk. In this case, it is all too common, once the code is integrated and manual system-level testing starts, for teams to become completelv overwhelmed bv defects. Arguments break out between testers, developers, and management, release dates slip, and users get landed with poor-quality software."
101: "In many projects, testing is treated as a distinct phase carried out by specialists. However, high-quality software is only possible if testing becomes the responsibility of everybody involved in delivering software and is practiced right from the beginning of the project and throughout its life. Testing is primarily concerned with establishing feedback loops that drive development, design, and release. Any plan that defers testing to the end of the project is broken because it removes the feedback loop that generates higher quality, higher productivity, and, most importantly of all, any measure of how complete the project is."
"The shortest feedback loops are created through sets of automated tests that are run upon every change to the system. Such tests should run at all levels-from unit tests up to acceptance tests (both functional and nonfunctional). Automated tests should be supplemented with manual testing such as exploratory testing and showcases."
119: There is a figure that helps prevent the CD pipeline from getting behind when teams are checking in very frequently. If the CD pipeline is currently running "build & unit tests" on version 1, and version 2 and 3 are committed. When version 1 is done, the pipeline should now build off the most recent version available. Otherwise the builds will get further and further behind.
The same idea applies to the "automated accepted tests" phase. As this phase will run even longer than the "build & unit test" phase, it should follow a similar process. The CI system's scheduler notices new changes and trigger a new run of the accept tests against the latest version. This intelligent scheduling is crucial.
120: "A new instance of your deployment pipeline is created upon every check-in and, if the first stage passes, results in the creation of a release candidate."
Congrats on adding Continuous Delivery by Jez Humble, David Farley to your bookshelf, I hope you enjoy it! It has an average of 3.5/5 stars and 3 ratings on Google Books.
Book details (JSON)
```json { "title": "Continuous Delivery", "authors": [ "Jez Humble", "David Farley" ], "publisher": "Pearson Education", "publishedDate": "2010-07-27", "description": "Winner of the 2011 Jolt Excellence Award! Getting software released to users is often a painful, risky, and time-consuming process. This groundbreaking new book sets out the principles and technical practices that enable rapid, incremental delivery of high quality, valuable new functionality to users. Through automation of the build, deployment, and testing process, and improved collaboration between developers, testers, and operations, delivery teams can get changes released in a matter of hours— sometimes even minutes–no matter what the size of a project or the complexity of its code base. Jez Humble and David Farley begin by presenting the foundations of a rapid, reliable, low-risk delivery process. Next, they introduce the “deployment pipeline,” an automated process for managing all changes, from check-in to release. Finally, they discuss the “ecosystem” needed to support continuous delivery, from infrastructure, data and configuration management to governance. The authors introduce state-of-the-art techniques, including automated infrastructure management and data migration, and the use of virtualization. For each, they review key issues, identify best practices, and demonstrate how to mitigate risks. Coverage includes • Automating all facets of building, integrating, testing, and deploying software • Implementing deployment pipelines at team and organizational levels • Improving collaboration between developers, testers, and operations • Developing features incrementally on large and distributed teams • Implementing an effective configuration management strategy • Automating acceptance testing, from analysis to implementation • Testing capacity and other non-functional requirements • Implementing continuous deployment and zero-downtime releases • Managing infrastructure, data, components and dependencies • Navigating risk management, compliance, and auditing Whether you’re a developer, systems administrator, tester, or manager, this book will help your organization move from idea to release faster than ever—so you can deliver value to your business rapidly and reliably.", "image": "http://books.google.com/books/content?id=6ADDuzere-YC&printsec=frontcover&img=1&zoom=1&edge=curl&source=gbs_api", "language": "en", "averageRating": 3.5, "ratingsCount": 3, "categories": [ "Computers" ], "pageCount": 512, "isbn10": "0321670221", "isbn13": "9780321670229", "googleBooks": { "id": "6ADDuzere-YC", "preview": "http://books.google.com/books?id=6ADDuzere-YC&printsec=frontcover&dq=intitle:Continuous+Delivery&hl=&cd=4&source=gbs_api", "info": "https://play.google.com/store/books/details?id=6ADDuzere-YC&source=gbs_api", "canonical": "https://play.google.com/store/books/details?id=6ADDuzere-YC" } } ```