Synopsis:
Does this sound familiar? You're expected to produce releases at an ever-increasing rate. You're under pressure to add new features and deploy to customers sometime between your first cup of coffee in the morning and lunch, if you have time to eat it. In the meantime, you have the same release processes you've always had and it's got problems. Maybe there's some automation, but there's room for lots of improvement. Manual steps are everywhere, everyone has a different environment, and working all weekend to get a release into production is normal.
One of the biggest problems is that changing how your software is released won't happen by waving a magic wand or writing a memo. It comes through effort, time, and money. That takes commitment from every group involved in the software process: test, development, IT (operations), and management. Finally, change is scary. Your current release process bears no similarity to the well-oiled machines you've seen in a dozen PowerPoint presentations, but it’s yours, you know its quirks, and you are shipping. This book is here to help you with some of these challenges. It explains how to progressively evolve the process you use to release software. There are many ways to improve the release process. We largely focus on how to improve its implementation, the release pipeline, by using and customizing the default build templates provided by Team Foundation Server (TFS) and Lab Management. We move forward in small iterations so that no single change you make is too drastic or disruptive.
The goal of this book is to put you on the road toward continuous delivery. By continuous delivery, we mean that through techniques such as versioning, continuous integration, automation, and environment management, you will be able to decrease the time between when you first have an idea and when that idea is realized as software that's in production. Any software that has successfully gone through your release process will be software that is production ready, and you can give it to customers whenever your business demands dictate. We also hope to show that there are practical business reasons that justify every improvement you want to make. A better release process makes economic sense.
About the Author:
Larry Brader has been a Senior Tester in the patterns & practices group at Microsoft for several years. He currently works as a test lead on the various p&p projects, focusing on client and server side. In addition he is interested in producing and shipping books of test guidance based on ALM. Before working at Microsoft, Larry worked on developing highly fault tolerant military & medical systems.
Roberta Leibovitz is a senior technical writer who has documented a variety of topics such as Agile development processes, automated configuration and deployment, and many web technologies. She is a principal with Modeled Computation LLC in Seattle.
Jose Luis Soria Teruel works as a ALM Team Lead at Plain Concepts, where he helps clients to improve development, delivery, quality, and lifecycle for their software. He has trained and coached dozens of teams during the last years, both as an independent trainer and as a Professional Scrum Trainer for Scrum.org (http://courses.scrum.org/about/jose-teruel). He is a MCSD in Application Lifecycle Management and has been nominated as Microsoft Active Professional (MAP) in 2013. He also regularly engages as a speaker at many events (http://www.slideshare.net/jlsoria/presentations), including the ALM Summit 3 (Redmond), Microsoft TechEd Middle East 2011 (Dubai), Scandinavian Developers Conference 2012 (Gothemburg), XP2011 (Madrid), Agile Portugal 2011 (Porto), Microsoft ALM Sessions and Cloud Day 2012 (Madrid and Barcelona), and all the editions of the Agile Spain Conference that have taken place so far. Jose (sporadically) writes at his blog (http://geeks.ms/blogs/jlsoria/) both in Spanish and English, and tweets as @jlsoriat.
"About this title" may belong to another edition of this title.
