DevOps is derived from two different words: development and operations. So as the word suggests, it describes a set of practices in a process while developing software and managing operations tasks.

DevOps as a term was first coined in 2008 by Andrew Shafer and Patrick Debois, who became two of its chief proponents, and since 2009 the term has been widely used and promoted with the goal of unifying the process of software development and operations.

DevOps is not just a set of practices, but also a way of working in the software development industry; it's a cultural change in the way development and operations work together.

Delivering technology to your customers at speed, and aligned to their needs, is key to future growth; this is a practice and can be achieved using DevOps. Adopting DevOps can create a continuous delivery ecosystem that improves the quality and velocity of delivery with all the attendant benefits.

In the traditional method, developers write the code as per the requirements, in any local environment. Once the application is ready, the QA team test the application in an environment that is similar to their production environment.

Once testing is successful and the requirements have been met, the product is released to the operations team for deployment. As both teams are working independently, there is a high chance that the deployment of a version of an application may take a long time and may not work as expected.

However, in DevOps, the process is quite different. Here, developers, QA, and operations collaborate and use various tools for continuous development, integration, delivery, and monitoring, which helps fill a big gap and expedite the process.

In a way, each and every tool works independently but tightly integrated with each other. A faster and automatic release to operations enables stakeholders to quickly respond to changes and meet requirements.

In the past, software development used to be a totally separate process from operations. Releases used to be loosely integrated with the actual development process, thus sometimes creating differences in the way the development environment and the release or production environment worked.

Developers used to finish their development independently from operations, and then operations used to take care of the release and post-release tasks for the project.

This way of working used to work great when the waterfall-style software development model was popular, when every step was sequential, and releases used to be a long process.

In today's world, where agile is the new and popular software development method, more frequent releases are the delivery goals, and only an integrated environment gives that flexibility with the required stability and service quality.

The biggest cultural difference DevOps brings is pulling together different roles/people into a specific team with the same delivery goal.

People get to do what they are good at and get instant feedback. DevOps enables quick solutions in the case of a technical glitch and contributes to team health, individual satisfaction, and time efficiency and management.

For example, a process that used to take months is now executed in minutes. It turns environment provisioning from a new problem into a delight, at the press of a button.

DevOps has given us the facility and flexibility to invent and focus on actual business needs, instead of managing hours and weeks and months of operational tasks.

Sites such as Amazon, Facebook, LinkedIn, and Twitter are known to do deployments many times a day (sometimes every minute). To deploy that often, they can't break what is already running; they have to complement what is already there.

DevOps helps you to focus on industry logic and what is actually required, instead of maintaining, scaling, clusters, deployment, and much more.

DevOps, in a way, represents and promotes a change in IT culture, focusing on fast and frequent delivery by adopting agile development, simplifying practices in the context of the software development life cycle, including both development and operations.

DevOps focuses on people and culture, and seeks to improve collaboration and integration between development and operations teams. DevOps implementations utilize technologies that ensure integration and quick feedback, and thus ensure quality, particularly by using software process automation tools that can leverage an increasingly programmable and highly dynamic infrastructure from a development and operations life cycle point of view.

To really understand the benefits and differences of using DevOps, we must have an idea of how things used to work before DevOps. As shown here, operations used to not be integrated with the rest of the development cycle:

In the DevOps way of working, operations are involved in the development process from the initial stages. They have a better understanding of issues that might arise later and can work in the beginning to avoid them during the production stage. Developers get quick feedback and can act on the issues suggested by operations, and vice versa.

Mobile DevOps is quite similar to DevOps, but only applied to mobile. With that said, it brings new challenges that come with mobile application deployment and maintenance. When talking about mobile application development, there are a lot of new things to consider about deployment and feedback.

A web application just needs to be tested and quality-checked on a limited set of browsers, but for mobile applications the range is huge and not limited to a set of mobile devices or operating system versions. A large number of operating system versions available in the market need to be tested and tracked once the application goes live in production.

The main difference between DevOps and mobile DevOps is the tooling required to achieve the process. In mobile DevOps, the SDKs have to be built into the application code to track bug reports and crash reports when in production.

Feedback mechanisms become even more important because mobile apps have a more personal feel to them, and users gives very important feedback that can be then worked upon and applied to application improvements.

Continuous feedback and continuous development have become the most important things in mobile application development. Developers have to continuously act on the feedback given by customers and there must be tools used to ensure that the right customer feedback is received on time and acted upon. Channels have to be monitored and monitoring tools have to be kept in place at every stage of development and production release, to ensure users' views are understood and taken care of. Developers have to know what scenarios might be making the users' app crash on their phone, such as which screen users spend the most time on, and what activities users don't perform in the application. All this feedback is important in mobile application development; to be able to get this feedback, tools should be in place, tools that enable continuous feedback and allow developers to have a better view of users' experiences.

When it comes to mobile applications, app crashes are not the only available feedback mechanism. Users can submit feedback directly from the mobile app to the developers. Some tools also provide user metrics and custom events, letting developers understand how the app is being adopted and used. All this information should be utilized to improve your backlog, and developers should always feel confident about investing in the right area, based on the data.

DevOps and mobile DevOps are similar, yet different in the sets of tools they use to achieve the same goal. To better understand the difference between DevOps and mobile DevOps, let's go through each step in the application development and operation life cycle, and discuss the differences in approaches.

The development phase is almost the same for web and mobile application development, but at the same time, in mobile application development developers need to include SDKs and tools that will later help them track app crashes and user feedback, and better monitor users' activities. Mobile application developers can build a feedback mechanism into their application, with which they can ask users to submit feedback and even bug reports, which are often provided by the mobile operating system. There are even some SDKs mobile app developers can embed into their code to help feedback tracking and better end user interaction.

Tools such as HockeyApp provide this integration of user interaction and feedback directly to developers.

When it comes to testing, there is a big difference between the tools used for web application testing and mobile application testing. In web applications, the resources required to test the application are limited to a set of browsers and a limited number of operating system versions.

Manual testing is sometimes enough to ensure great quality products. But when it comes to mobile application testing, there are hundreds of different hardware-dependent combinations of devices that need to be tested to ensure your app will work fine when it goes live. After the rise of Android, there are so many different devices with a variety of hardware configurations and different operating systems. To ensure a wide user base, developers need to make sure their app is compatible with all the different versions and lower-end devices.

To quality-check such things, just testing on emulators is not enough for high-quality applications; they need to be tested on real-world devices, which is sometimes difficult and off-budget for many organizations. This is where cloud test environments such as Xamarin Test Cloud comes into the picture, to automate the process and test on real devices at low cost.

In a web application deployment, the environment can be controlled and customized to our needs, but in mobile application deployment, the application needs to be published through some sort of operating system application store, which then verifies and publishes the application to be used by users on their devices.

To monitor a web application, developers use logs, some tools at the server side, and others on the client side to help them identify issues that might arise because of network or code quality. But in mobile applications, the area is quite wide because of the issues that can occur. Various hardware dependencies, device permissions, and other factors can crop up that are difficult to monitor without proper tools involved, and that's where mobile DevOps differs from DevOps.

Continuous delivery sounds very simple and it sure is that way if done properly. In DevOps, getting feedback and then working on it, fixing bugs, and then redeploying them is much simpler and less time-consuming than in mobile applications. Getting crash reports from users, then finding out the issue, and then going through the testing phase again can be very time-consuming if not automated.

Automating the process of development, testing on real-world devices, then signing apps and publishing them to the store, and again tracking users' feedback—this entire process becomes very complicated if the right tools are not used.

Because of the fast and continuous delivery mindset, DevOps comes with many challenges, especially when applying DevOps to the mobile application development life cycle.

The following are some of the challenges that arise while applying DevOps to mobile.

Mobile technologies are rapidly evolving and improving every day, and with mobile devices getting released with new features and hardware support every day, it's difficult for DevOps tools to keep pace with them.

Most mobile applications have multiple platform targets; the operating systems have different versions and applications need to support most of them to ensure a large user base. With Android, for example, many devices have old versions installed and do not get updated to later versions because of hardware limitations, and because manufacturers don't update their devices. At the same time, having different devices means customizing Android to suit personal taste and changing the user interface, and thus applications have to be compatible with all the different form factors and UI changes.

Mobile applications are now an integral part of many organizations' frontends, and clearly drive changes to backend development as well. Organizations use service layers and data layers to do backend operations, but due to integration with mobile development, they need to better adapt to, and collaborate with, mobile and web development.

Because how releases and updates are consumed over mobile platforms is totally different from the web, it becomes more difficult to ensure updates are made and care about old versions. On mobile, users have to download the update; the application doesn't get updated automatically, as it does on the web whenever users access the URL. Most of the time, users choose not to download the update, and sometimes they have storage restrictions. So, application developers have to consistently make sure everything works on old and new versions.

As described earlier, mobile applications need to be working on new and old versions of operating systems. Just because you've developed new versions does not mean people on older versions are not your responsibility anymore. As it turns out, the majority of people who use older versions of operating systems don't download the latest updates. App developers have to use the latest features in new versions of the OS and at the same time they should make sure apps run perfectly fine on older versions as well.

This is a new method of app distribution, mostly found in the mobile app industry. In web apps, you just have your application deployed on your web server and a URL where interested people can access your application.

Fixing issues and deploying patches becomes so easy, since you just have to deploy it on your servers and people accessing your web application will receive it immediately.

In mobile applications, apps must go through app stores in all different operating systems.

They must be verified before they can be published, and even updates and small patches need to go through the same route, so fixes are not available to end users immediately. This creates an extra step in the complexity of applying DevOps to mobile.

In the web and other platforms, since the application is not going to the user through an application store, the feedback is personal to the application team. User feedback is not visible to other users, and they get to judge and use it as they see fit.

In mobile devices, users can give feedback on the application store and if the application does not live up to the expectations of users, it gets bad ratings that hurt the application in a big way. This sort of quick and visible feedback can help an application take off, or see it fail miserably if users don't like it. Acting on such feedback becomes very important in mobile DevOps.

In this chapter, we discussed DevOps and mobile DevOps, what it means to implement DevOps, and how it changes the way different teams work together. We also described the key difference between DevOps and mobile DevOps in various stages of development and operations. In the next chapter, you'll be learning about one of the most important aspects of DevOps, which is source code management.