- Copertina rigida: 463 pagine
- Editore: ADDISON WESLEY LONGMAN INC DIV PEARSON SUITE 300; 01 edizione (27 luglio 2010)
- Collana: Addison Wesley Signature Series
- Lingua: Inglese
- ISBN-10: 0321601912
- ISBN-13: 978-0321601919
- Peso di spedizione: 939 g
- Media recensioni: 4.7 su 5 stelle Visualizza tutte le recensioni (3 recensioni clienti)
- Posizione nella classifica Bestseller di Amazon:
Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation (Inglese) Copertina rigida – 27 lug 2010
|Nuovo a partire da||Usato da|
Spesso comprati insieme
Chi ha acquistato questo articolo ha acquistato anche
Non è necessario possedere un dispositivo Kindle. Scarica una delle app Kindle gratuite per iniziare a leggere i libri Kindle sul tuo smartphone, tablet e computer.
Per scaricare una app gratuita, inserisci l'indirizzo e-mail o il numero di cellulare.
Garanzia e recesso: Se vuoi restituire un prodotto entro 30 giorni dal ricevimento perché hai cambiato idea, consulta la nostra pagina d'aiuto sul Diritto di Recesso. Se hai ricevuto un prodotto difettoso o danneggiato consulta la nostra pagina d'aiuto sulla Garanzia Legale. Per informazioni specifiche sugli acquisti effettuati su Marketplace consulta… Maggiori informazioni la nostra pagina d'aiuto su Resi e rimborsi per articoli Marketplace.
Quali altri articoli acquistano i clienti, dopo aver visualizzato questo articolo?
Principali recensioni dei clienti
I benefici della CD sono abbastanza evidenti:
Tempi di reazione più rapidi – Il vantaggio più evidente del CD è che consente reazioni rapide agli stimoli, sia esterni che interni, per esempio la classica riduzione degli sprechi finanziari oppure l'implementazione di "quello che non va fatto" nell'ambito della gestione della sicurezza delle informazioni.
Rischio ridotto – Capita a molte organizzazioni di focalizzarsi troppo sulla forma delle procedure di rilascio. È corretto porre attenzione a questa fase delicata, perché dopo il rilascio, l'applicazione è nelle mani del cliente e tutto deve andare bene. Il rovescio della medaglia è che per garantire che tutto vada nel verso giusto, occorre investire tempo e risorse per costituire un buon team di QA (Quality Assurance) oltre che quello di Release Engineering. In questo senso va inteso il rispetto della "forma" nelle procedure, come fosse una sorta di revisione continua (e quindi miglioramento continuo) del processo di rilascio stesso.
Individuazione chiara dei costi e delle inefficienze– Sia che si tratti di un servizio sul WEB che di una copia master ISO, ogni organizzazione software affronta un certo costo per consegnare "i bit" al cliente.Ulteriori informazioni ›
Non lo consiglierei a chi vuole una guida molto specifica
Pragmatic, accurate, achievable, not fluffy at all.
Le recensioni clienti più utili su Amazon.com (beta)
That said, there are some good gems inside. My favorite parts might be the many real-world stories of how things can go wrong or how applying some of the principles smoothed things out. The detail, diversity and verisimilitude of those anecdotes sets the book apart from many books in the field.
I wish I could say this was a "must have" book, but it's really more of a "must skim" sort of book.
To sum up key points from the book in a few bullets:
* The purpose of Continuous Delivery is to reduce the cycle time between an idea and usable software
* Automate (almost) everything necessary to create usable software
* Version complete software systems (not just source code) for every change committed to version control system
* Employ a Deployment Pipeline in which the entire system is recreated whenever a change is committed to the version-control system and provide continuous feedback
* Identify one delivery team consisting of various delivery experts - build, deploy, provisioning, database, testing, etc. - a concept emphasized in the DevOps movement
The authors go into great detail in describing each of these themes. So, if you want the process of delivering software to any target environment - including production - to be a click of a button and something that can be accomplished as often as the business requires, get this book. When you employ the practices in this book, no longer will you need to artificially throttle changes delivered to users for months or even years because of the expense and risk required to deliver software.
Continuous delivery consists of three parts: 1) Foundation, 2) Deployment Pipeline, and 3) Delivery Ecosystem
The first four chapters cover the fundamentals the rest of the book is based on. The first chapter provides some problems with more traditional approaches and also introduces some principles extracted out of continuous delivery. The next three chapters cover topics that provide the basics of continuous delivery. Someone involved with agile development for a while is probably aware of most of this and it will be a quick read. For new people, these chapter provide a quick introduction to these topics so that you can understand the rest of the book. The chapters are: "configuration management," "continuous integration," and "implementing a testing strategy."
The second part is the core of the book. It explains the continuous delivery pipeline. This pipeline is a series of stages (a series of continuous integration systems) each stage covering higher-level wider-range of testing so that the confidence in the product increases the later the stage in the deployment pipeline passes. The stages the authors recommend in the deployment pipeline are: commit, acceptance, capacity, manual, production. Each of these stages (except for manual) has its own chapter which explains tools and practices that the authors have found useful in that stage of the deployment pipeline. The part also contains an additional 'foundation' chapter about build and deployment scripting.
The last part of the book is one that I myself found most interesting which covers perhaps some 'advanced' topics. The part is called "delivery ecosystem" and the chapters aren't directly related to each other but each chapter covers a common topic related to the deployment pipeline. Chapter 11 talks about managing and automating your infrastructure as part of your build also. It introduces a vast amount of topics related to automation (pupper, chef), virtualization, cloud computing and monitoring. Unfortunately, the book is only able to touch a little upon each of these topics as each of them could easily fill several others books (and they do!). Chapter 12 covers a very frequent problem in testing and test automation related to managing data. It explains several different approaches and then evaluates them and shares the experiences and recommendations of the authors. Managing test data is a common problem and is rarely covered in the amount of detail as this book does. Chapter 13 discusses different scaling options by componentizing the product and what effect this has on the continuous deployment pipeline (basically adding another dimension to the pipeline). Chapter 14 is about version control and can be summarized as "avoid branching" but the authors do a good job explaining that message and why the alternatives are indeed worst. Chapter 15 was a short (and I slightly disliked this chapter) about managing continuous delivery. It felt like the standard "and now... what actions to take"-chapter. It was a bit shallow though.
When the book was published, I read it through rather quickly and liked it but didn't appreciated the depth of the book yet. I re-read it the second time more thoroughly and enjoyed the careful comparisons and explanations of the recommendations of the authors. They shared the experiences they have had very clear. The book is interesting to me as it covers a vast area and thus it is hard to not touch everything shallowly, but they don't, they go in more depth at the points where the authors feel it is appropriate (for example, parts that are controversial or often done differently).
The book isn't perfect though! As some other reviewers pointed out, it is repetitive and should have been thinner. I agree with that. Also, sometimes the book side-tracks in interesting facts that are unlikely to help the reader a lot such as the history of version control. Next, the book contains some very basic things that could have perhaps been left out (or put as appendix), such as an explanation of maven. My last comment is that the book sometimes contradicts itself such as the recommendation to do things "at the beginning of the project" but then later stating that "at the beginning of the project, all these decisions will change". There I still felt the influence of standard 'project' thinking.
With all these drawbacks, I still decided to rate the book five stars because I do think it is an very influential and important book. It tells and *shows* that continuous delivery is not just a perfection state but that it can be achieved today. Not only that, it can be achieved in larger projects, not just small web projects. This is a huge contribution to the industry and I think and hope that the practices of continuous delivery will become standard practices everywhere. Excellent read (except for the repetition) and highly recommended.
I don't rate this book as just 1 star, as it has some good ideas, but it could have been written in 150 pages (max) rather than 450. Some of the concepts that are repeated until boredom are:
- Don't build the binaries at each stage of the deployment pipeline, create them once an reuse them.
- The capacity testing environment should be as similar as possible to the production environment.
- Script everything!
- Don't let builds that fail unit or acceptance test into production
- Put all the configuration in version control (network, firewall, OS, etc)
I also found the book more directed to manager who don't really know or care about the technology, but want to talk "in techie" language to their engineers. There are too few examples of how to use technology to build a deployment pipeline and most of the talk stays at a very abstract level.
My bottom line, I strongly suggest to read some blog posts and watch some presentations (check infoq) about this subject, it takes less time and it's more enriching than reading this book.
Continuous Delivery advocates a closer collaboration between all stakeholders that are involved in the software development process. It delivers a holistic approach to software engineering. The book underlines the importance of aspects like Continuous Integration, acceptance testing and component repositories, and discusses many common and valuable best practices. It discusses questions that are relevant for different project phases and stakeholders. The book delivers the authors' views and opinions in a very informative way.
The book does not discuss all possible questions along all development phases (just not possible). It assigns priorities where, in some cases, you may miss another controversal aspect of the discussion (e.g. in the context of "keep absolutely everything in version control"). The pragmatic discussion of "configuration management" will be helpful for many teams, though. In other cases, you may miss another hint or little step. One example for that is in the context of "meaningful commit messages". Here, the potential of task-based development is not really illustrated, maybe because due to the next fact: The book does not (or rarely) show how to implement the strategies with tools. Some sections illustrate tools. Because it is not possible to cover all build tools for all different languages and platforms in one book, such sections give you a nice first impression, though. But for me, these sections are optional for such a book, for a book that is platform/language agnostic. These points are not disadvantages or drawbacks, you should just now them. As always, you should read the Preface first, to understand what this book is, and what it is not. Such a great book cannot cover every single aspect. And there are books like "Agile ALM", which assign other priorities, add other aspects to the discussion and are more targeted to a specific platform/audience (Java/JEE).
Continuous Delivery illustrates an approach that "all code changes are entering a pipeline" to production. I like this nice metaphor for promoting software, staging artifacts from the development team to the final release in production. Some people may claim that this is part of "release management", others may say it is similar to Continuous Integration, and "Continuous Deployment" (deploying versions to production, and to test machines before, continuously). - In my opinion, a change may result in a release *potentially* and *may* start the whole process. And: no changes to the production system without any process; most of the changes will be staged along the full way. The process and the infrastructure must enable the team to promote every single change to production, if you want to do that, however.
Additionally, I think that you should take special care of linking all artifact types to consistent releases, and that you should realize the "pipeline" not as something like a "fire-and-forget" tube. In my opinion, development phases are connected and integrated, and in most cases, it is (hopefully) more an integrated lifecycle, something like a pipline, where both ends of the cube are connected with each other.
Continuous Delivery is a very important contribution. I recommend the book to everyone involved in software engineering.