For any software developer who has spent days in “integration hell,” cobbling together myriad software components, Continuous Improving Software Quality and Reducing Risk illustrates how to transform integration from a necessary evil into an everyday part of the development process. The key, as the authors show, is to integrate regularly and often using continuous integration (CI) practices and techniques. The authors first examine the concept of CI and its practices from the ground up and then move on to explore other effective processes performed by CI systems, such as database integration, testing, inspection, deployment, and feedback. Through more than forty CI-related practices using application examples in different languages, readers learn that CI leads to more rapid software development, produces deployable software at every step in the development lifecycle, and reduces the time between defect introduction and detection, saving time and lowering costs. With successful implementation of CI, developers reduce risks and repetitive manual processes, and teams receive better project visibility. The book covers The book’s companion Web site, , provides updates and code examples.
Writing production grade software, integrating it, and deploying it without going through this book is like shitting in a bucket and pouring it over the side of your window. Most of the time you can "probably make it work", and because "it works" you might even think you're doing the right thing, but one day, someone--maybe a teammate, maybe you-- will be walking along the windowsill and the solution will fall like "manna from heaven."
It's always been a point of personal exasperation/professional embarrassment about the pervasiveness of ignorance in my field when I have to explain to other "senior" developers that there's a difference between unit/component(integration)/system(~ functional) tests. Now I'm just going to throw the section about testing at them. Excellent breakdown.
I always thought the idea of testing and automating database creation and data population was "cute"...this book made me realize how absolutely vital it is. Too many times I've seen dev teams shackled by "the dev/integration database is down/has bad data" and the solution is astonishingly simple. So much effort wasted on making/fixing batch jobs, pushing forward with broken tests because of "known issues"... it's another embarrassing trend.
I'm not as sold on the centralized build machine in the age of Containers. I think conceptually it made a lot of sense at the time to keep environmental dependencies to a minimum--and I'm sure illustrious hackers can find a way to bake local environmental assumptions into Container images-- but it still feels to me like a lot of the work done in a "private build" is essentially duplicated simply for the "clean room reproducibility" a CI server provides, which now comes close to guaranteed in a shrink-wrapped image.
I do think that the "staged build" concept provides an opportunity to argue for its continued existence. A "lightweight build" that executes the tests and prepares the deployable artifact could be run locally, while some of the longer inspections and analysis (load testing, bake in testing, A/B testing) could work on the CI server. Obviously you can exert maximum control by only allowing the CI server to carry out full deployment to Prod, but there's an argument to be made that this handcuffs skilled developers in failure mode situations.
Having seen (and driven) pushes towards full CI/CD (which I think it may be helpful to separate), it seems once again (like that mythical unicorn) that this is another one of the 12 practices of XP that really shines when the others are in place. Releases have to be small and frequent which implies changes have to be small and frequent, which implies the devs have to specify, design, and implement in a way that makes code easy to test and refactor. CD, as a separate problem space, can be potentially simplified with enough automation and tooling with sufficient workflows to promote/rollback fairly easily.
The final nit is that a lot of the tools are obviously almost a decade old and the market has changed significantly since then. It may have been helpful to just throw the last section away and focus more on the concepts. The evaluation criterion in the appendix was interesting, and may be a target for a "quick cheat sheet" to fill out when analyzing tools.
The entire book can be reduced to two slides: one diagram and one bullet list of pros and cons. The diagram shows up again and again; they use it as a map to the contents, highlighting the current section. Each time, the diagram takes about three quarters of the page. It is not a very busy diagram and if could easily have been made smaller.
So far, it is very repetitive. They keep repeating the same things over and over. They keep promising that topics will be covered in more depth in later chapters, but I am still waiting.
In the end, the whole book could be reduced to that one diagram and a short bullet list of pros and cons. I was pretty disappointed. But if you need to sell a continuous build to someone who is not technical and does not understand programming, maybe this is a book for that.
Even though I had little expectations from this book, after going over a couple of reviews on Goodreads I still decided to go ahead and read it. I think if you're new to this whole CI thing, this is a great book to start with, even if some of the tools presented are no longer that recent/relevant. It goes over many good practices, and all the practices and recommendations are not only still relevant, but surely there are still many teams and companies out there today, that are still not following them.
Automating builds, failing fast and using a dedicated build machine for quicker builds is common sense today, but considering that this is a 2009 book, it is rather impressive that not everyone is not fully on-board with the ideas presented in here. Funny thing is, some of the tools presented are no longer available at this point, while others have become de-facto standards.
I would recommend this book for everyone who needs to have an introduction to the whole CI (Integration) and CD (Delivery) of software, and get some solid good practices from the automation side.
Great book to start working on Continuous Integration. Most tools recommended are more focused on Java development and some for .Net. Definitely suggest this book for contemporary as-well-as veteran software engineers and quality assurance engineers.
Excellent read! So many developers fail to set up a reliable Continuous Integration system for their project. This book is a practical guide that changes your way of thinking about topics like Software Quality and Risk.
Not bad. Book often seemed to presume that the reader took a dismissive stance towards the benefits of CI. Often read like a collection of powerpoint presentation essays. Skipped around a bit between topics. Mostly Java-centric, but what is not nowadays. Disliked the stilted/weird dialog of faceless characters having arguments/discussions surrounding CI topics. The jagoff DBA, the cowboy coder, the clueless dev, and so on. Not bad, could have been better, but was probably great for the time. If anything, the first chapter graphic explaining CI and what all can be expected out if it was useful. Most people think of the CI server as the "build" machine, but don't seem to expand that definition to areas of feedback generation, DB integration, and deployment. Good stuff and a brisk read, with an appendix full of products that may likely still exist in the tech field now.
Let me be clear: I liked the information that was provided. Very useful and applicable to software engineering, and it really changed the way I look at development processes and continuous integration.
But it was way too wordy. I think the information could have been conveyed much more succinctly. The great nuggets of information were watered down with too many justifications and narratives and perspectives.
It's a good general overview of CI. It's focused on java domain, but most of the stuff is applicable to .Net domain as well. It's a good book for people who is new to CI, but for me it wasn't much interesting.
It's a comprehensive overview of CI methodology and tooling. It's worth reading for a newbies. Those who have CI experience may learn just a thing or two there but still it may be a good reading for them. You may find it also useful if you are migrating from Java to .NET or vice-versa.
Good introduction to Continuous Integration. Broad in scope and fairly basic, a quick read. Contains a lot of material about specific tools (the appendix is 15% of the book), but since it was published in 2007, that is all out of date.
I didn't like it, could a 10th thinner and deliver the same content. Once you finish the first chapters about what CI is (and not from any breakthrough perspective) the rest of the book isn't more than going over and over of the same idea and present some tools, mainly for Java projects.
This is a general overview of CI, with examples from the java domain. There are no great revelations - but if you are new to CI, then it gives a good overview of the ideas