• Complain

De Kort - DevOps on the Microsoft Stack

Here you can read online De Kort - DevOps on the Microsoft Stack full text of the book (entire story) in english for free. Download pdf and epub, get meaning, cover and reviews about this ebook. City: Berkeley;CA, year: 2016, publisher: Apress, genre: Business. Description of the work, (preface) as well as reviews are available. Best literature library LitArk.com created for fans of good reading and offers a wide selection of genres:

Romance novel Science fiction Adventure Detective Science History Home and family Prose Art Politics Computer Non-fiction Religion Business Children Humor

Choose a favorite category and find really read worthwhile books. Enjoy immersion in the world of imagination, feel the emotions of the characters or learn something new for yourself, make an fascinating discovery.

De Kort DevOps on the Microsoft Stack
  • Book:
    DevOps on the Microsoft Stack
  • Author:
  • Publisher:
    Apress
  • Genre:
  • Year:
    2016
  • City:
    Berkeley;CA
  • Rating:
    4 / 5
  • Favourites:
    Add to favourites
  • Your mark:
    • 80
    • 1
    • 2
    • 3
    • 4
    • 5

DevOps on the Microsoft Stack: summary, description and annotation

We offer to read an annotation, description, summary or preface (depends on what the author of the book "DevOps on the Microsoft Stack" wrote himself). If you haven't found the necessary information about the book — write in the comments, we will try to find it.

This book tells you everything you need to know to help your organization implement DevOps on the Microsoft platform. You will learn how to use Visual Studio, Visual Studio Team Services, and Azure to implement a complete DevOps process in your company. You will learn about Agile Project Management, Continuous Integration, Continuous Delivery, Technical Debt Management, Automatic Testing and Monitoring, and see how all these areas fit together. DevOps is important for organizations that want to make the best use of their resources and avoid costly mistakes. Teams that embrace DevOps deploy code up to 30 times more frequently than their competition and less than 50% of their deployments fail according to Puppet Labs State of DevOps survey. DevOps on the Microsoft Stack shows you how to help your organization implement DevOps, covering the tooling they will need and how to make everything work together while following best practices. The focus is not only on technology but also on the cultural issues that teams will face when implementing DevOps. The authors goal is to not only show you which tooling there is but help you to successfully use everything together to implement DevOps in your projects and organization. In this book, youll learn: What DevOps is and how it can help development teams How to use Visual Studio, Visual Studio Team Services, and Azure to setup a DevOps process How to introduce DevOps to your organization and how to overcome problems.

De Kort: author's other books


Who wrote DevOps on the Microsoft Stack? Find out the surname, the name of the author of the book and a list of all author's works by series.

DevOps on the Microsoft Stack — read online for free the complete book (whole text) full work

Below is the text of the book, divided by pages. System saving the place of the last page read, allows you to conveniently read the book "DevOps on the Microsoft Stack" online for free, without having to search again every time where you left off. Put a bookmark, and you can go to the page where you finished reading at any time.

Light

Font size:

Reset

Interval:

Bookmark:

Make
Part I
Getting Started
Getting Started
In this first part, youll learn what DevOps is and why it should interest you. You will be introduced to Microsofts tooling in the form of Visual Studio Team Services and Microsoft Azure.
Wouter de Kort 2016
Wouter de Kort DevOps on the Microsoft Stack 10.1007/978-1-4842-1446-6_1
1. What Is DevOps?
Wouter de Kort 1
(1)
Ordina Microsoft Solutions, GRONINGEN, The Netherlands
Electronic supplementary material
The online version of this chapter (doi: 10.1007/978-1-4842-1446-6_1 ) contains supplementary material, which is available to authorized users.
You might lately have heard a lot about the term DevOps. Gartner even stated that 2016 is the year of DevOps ( http://www.gartner.com/newsroom/id/2999017 ). Is DevOps more than a marketing term? Or is it just some hype that someone created?
Why Are We Doing DevOps?
Software development is still a young industry. As an industry, its rapidly evolving and trying to become better. And growth is really necessary. The software development industry doesnt have a very good reputation when it comes to producing software on time and on budget. In whats now called a waterfall process, software was developed in a couple of discrete steps. In Figure you see the steps a typical project used to have to develop software. All these phases follow each other and the total timespan could be several months or even years.
Figure 1-1 Stages in a waterfall project Other industries use the same kind - photo 1
Figure 1-1.
Stages in a waterfall project
Other industries use the same kind of distinct steps. For example, consider a city block where all houses are being built to look alike. It makes sense to have a clear specification of all the steps that go into building a house and then repeat those steps for all houses until the block is finished. Software is different. Customers dont ask developers to build them multiple copies of the same product. Instead, each project is unique. Development teams are always building something new. The problem with wanting something new is that you dont know exactly what you want since you first have to come up with an idea. Software development organizations thought the solution was to create better specifications. The documents that were created became bigger and bigger. And of course, creating a detailed upfront specification takes a lot of time. So customers were asked to sign those documents and then treat them as the absolute truth.
After the first analysis phase ends with a detailed specification, design, code, and test phases follow. After the first pass through the steps, a working version is demoed to the customer. The first time a customer sees a working version of his idea, he gets a better idea of what he actually needs. Maybe the customer wants some small changes or maybe he decides he wants something completely different. This has plagued the software industry for a long time and led to the reputation that the software industry builds the wrong thing, while missing deadlines and costing more than was promised. This is when a big step in the software industry was made: the beginning of Agile.
In 2001, the Agile Manifesto was released. The Agile Manifesto can be seen as a response to the state that software development was in. The Agile Manifesto stated a couple of simple values:
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
The Agile Manifesto
The Agile Manifesto caused a lot of change in the software industry. Instead of writing thick documents, development teams started actually working with the customer. The fact that a customer changes his mind was no longer viewed as something that a team needed to avoid. Instead, teams accepted that customers change their minds and that its their right to do so. Software development teams started working together with their customers. So instead of working for months or even years on a product and then finally showing it to the customer, teams started to involve customers in the process by delivering small iterations and responding to changes.
The most popular method based on the Agile Manifesto is Scrum . Scrum has a couple of key elements. A team is self-organizing with all required roles in it. The team works in short iterations called Sprints . The team is led by a product owner, preferably a customer. The product owner helps the team constantly adjust to changes by constantly reprioritizing and making sure that the team delivers the most business value.
Scrum took off. It took off huge. A lot of teams liked the idea and when I ask at a developer conference who is doing Scrum, I normally see all hands going up! (This doesnt mean that everyone is doing it right. Some teams only think they are doing Scrum.)
The story doesnt end with the invention of Agile and Scrum. If a team practices Agile well, the team will pick up speed. The developers, helped by the product owner, will create a steady release of new features. Agile is part of the solution but we needed more. Successful Agile teams still have barriers.
Testers often struggle in an Agile organization. They are always trying to keep up with the developers. The discipline of testers is changing and I see the distinction between testers and developers blurring. Testers and developers often pair up or blend into a multi-skilled developer role. While testers struggle to keep up, the situation is even worse for the operations team. These teams are often in another department. They are responsible for running the datacenter and are tasked with deploying applications that the development team creates while making sure that everything keeps running. This leads to silos, which are different teams in different departments reporting to different managers with different responsibilities. The operations team is responsible for making sure the software is stable. The development team is responsible for getting out new features as fast as possible. The testers are caught in between and the business only sees that the things they need take too long to become available.
In the years since the introduction of Agile, the software world has changed even more. Mobile systems and the cloud were big game changers. Customers have changed the way they interact with companies and startups take advantage of this. A company like Uber suddenly competes with the regular taxi world. PayPal, which is a software company, competes with banks. Netflix has revolutionized the way people watch TV. How have these companies succeeded?
This is where DevOps come in. DevOps helps Agile to fully realize its potential. The opinions on what DevOps is differ, but I like the following definition :
DevOps is the union of people, process, and products to enable continuous delivery of value to our end users.
Donovan Brown, DevOps Senior Program Manager at Microsoft
The key phrase is continuous delivery of value. Where Agile helped the software industry respond to customer needs and keep up with changes, DevOps is the key to actually delivering the value to the hands of the end users. DevOps is more than tooling. DevOps is about the whole organization working together to deliver value to its customers. This makes DevOps as much about people and processes as it is about choosing the right tools. DevOps helps you in optimizing whats called the software delivery pipeline , which involves taking software from an idea to the hands of the end user. By putting DevOps patterns into practice, organizations like Netflix, Facebook, Amazon, Twitter, Google and Microsoft are achieving levels of performance that were unthinkable while using Agile. These organizations dont deploy once a year or even once a week. Instead they deploy multiple times a day while delivering a stable and reliable user experience.
Next page
Light

Font size:

Reset

Interval:

Bookmark:

Make

Similar books «DevOps on the Microsoft Stack»

Look at similar books to DevOps on the Microsoft Stack. We have selected literature similar in name and meaning in the hope of providing readers with more options to find new, interesting, not yet read works.


Reviews about «DevOps on the Microsoft Stack»

Discussion, reviews of the book DevOps on the Microsoft Stack and just readers' own opinions. Leave your comments, write what you think about the work, its meaning or the main characters. Specify what exactly you liked and what you didn't like, and why you think so.