Book Image

DevOps with Windows Server 2016

Book Image

DevOps with Windows Server 2016

Overview of this book

Delivering applications swiftly is one of the major challenges faced in fast-paced business environments. Windows Server 2016 DevOps is the solution to these challenges as it helps organizations to respond faster in order to handle the competitive pressures by replacing error-prone manual tasks using automation. This book is a practical description and implementation of DevOps principles and practices using the features provided by Windows Server 2016 and VSTS vNext. It jumps straight into explaining the relevant tools and technologies needed to implement DevOps principles and practices. It implements all major DevOps practices and principles and takes readers through it from envisioning a project up to operations and further. It uses the latest and upcoming concepts and technologies from Microsoft and open source such as Docker, Windows Container, Nano Server, DSC, Pester, and VSTS vNext. By the end of this book, you will be well aware of the DevOps principles and practices and will have implemented all these principles practically for a sample application using the latest technologies on the Microsoft platform. You will be ready to start implementing DevOps within your project/engagement.
Table of Contents (20 chapters)
DevOps with Windows Server 2016
Credits
About the Author
Acknowledgments
About the Reviewer
Acknowledgments
www.PacktPub.com
Customer Feedback
Preface

Software delivery challenges


There are inherent challenges when engaged in the activity of software delivery. It involves multiple people with different skills using different tools and technologies with multiple different processes. It is not easy to bring all these together in a cohesive manner. Some of these challenges are mentioned in this section. Later, in subsequent chapters, we will see how these challenges are addressed with the adoption of DevOps principles and practices.

Resistance to change

Organizations work within the realms of economic, political, and social backdrops, and they have to constantly adapt themselves to a continuously changing environment. Economic changes might introduce an increase in competition in terms of price, quality of products and services, changing marketing strategies, and mergers and acquisitions. The political environment introduces changes in legislation, which has an impact on the rules and regulation for enterprise. The tax system and international trade policies are also examples of areas in which change can have an impact. Society decides which products and services are acceptable or preferred and which are discarded. Customers demand change on a constant basis. Their needs and requirements change often and this manifests in the systems they are using. Organizations not adept at handling changes in their delivery processes and who resist making changes to their products and features eventually find themselves outdated and irrelevant. These organizations are not responsive to change. In short, the environment is ever changing and organizations perish if they do not change along with it.

Rigid processes

Software organizations with a traditional mindset release their products and services on a yearly or multi-year basis. Their software development life cycle is long and their operations do not have many changes to deploy and maintain. Customers demand more but they wait till the next release from the company. The organization is either not interested or does not have the capability to release changes faster. Meanwhile, if the competitor is able to provide more and better features faster, customers will soon shift their loyalty and start using them. The first organization will start losing customers, have reduced revenues, and fade away.

Isolated teams

Generally, there are multiple teams behind any system or service provided to the customer. Typically, there is a development team and an operations team. The development team is responsible for developing and testing the system, while the operations team is responsible for managing and maintaining the system on production. The operations team provides post-deployment services to the customer. These two teams have different skills, experience, mindset, and working culture. The charter of the development team is to develop newer features and upgrade existing ones. They constantly produce code and want to see it in production. However, the operations team is not comfortable with frequent changes. The stability of the existing environment is more important to them. There is a constant conflict between these two teams.

There is little or no collaboration and communication between these two teams. The development team often provides code artifacts to the operations team for deployment on production without helping them to understand the change. The operations team is not comfortable deploying the new changes since they are neither aware of the kind of changes coming in as part of a new release nor have confidence deploying the software. There is no proper hand-off between the development and operations teams. Often, the deployments fail on production and the operations team has to spend sleepless nights ensuring that the current deployment is either fixed or rolled back to a previous working release. Both the development and operations teams are working in silos. The development team does not treat the operations team as equivalent to itself. The operations team has no role to play in the software development life cycle, while the development team has no role to play in operations.

Monolithic design and deployments

Development goes on for multiple months before testing begins. The flow is linear and the approach is Waterfall, where the next stage in software development life cycle happens only when the prior stage is completed or nearing completion. Deployment is one giant exercise in deploying multiple artifacts on multiple servers based on documented procedures. Such practices have many inherent problems. There are a lot of features and configuration steps for large applications and everything needs to be done, in order, on multiple servers. Deploying a huge application is risky and fails when a small step is missed during deployment. It generally takes weeks to deploy a system such as this in production.

Manual execution

Software development enterprises often do not employ proper automation in their application lifecycle management. Developers tend to check-in code only after a week, the testing is manual, configuration of the environment and system is manual, and documentation is either missing or very dense, comprising hundreds of pages. The operations team follows the provided documentation to deploy the system manually on production. Often this results in a lot of downtime on production because smaller steps have been missed in deployment. Eventually, customers become dissatisfied with the services provided by the company. Also, this introduces human dependencies within the organization. If a person leaves the organization, their knowledge leaves with them and a new person has to struggle significantly to gain the same level of expertise and knowledge.

Lack of innovation

Organizations starts losing out to competition when they are not flexible to meet customer expectation with newer and upgraded products and services. The result is falling revenues and profits, eventually making them nonexistent in the marketplace. Organizations that do not innovate newer products and services consistently nor update them cannot provide exponential customer satisfaction.