DevOps, as a big word has taken a solid niche and it is not going anywhere. But, what exactly is DevOps? DevOps is one of most used terms in computer science, and one of the most misunderstood terms in the computer science as well. Beginners, students and non-technical people often mistake it for a product, tool or an administrative package available for IT Pros or the Ops management team. But that is not true. DevOps is a lot more than any of that, and much less than any of these tools or products may have as a complexity or difficulty. Let me formally define the term of DevOps, and then I will explain why I think that this is the way it must be,
DevOps, in software engineering, is a mindset of an entire team (or organization), that transforms their software inception, development, deployment and management tasks to support customer requirements, development needs and faster product launches.
So yes, the DevOps is a practice, must like Agile development, Waterfall development model or the V-shaped model.
On every platform, and on every product that serves the basic functionality for DevOps-oriented teams, the explanation or definition of DevOps is made differently. That is because it is upto them, for what they want you to visualize the DevOps as. Think of two different firms, one that provides a software toolchain for DevOps-based software development, and the other one that provides training for DevOps.
Software development can be tough and if done incorrectly can be a painful path, we understand, which is why we provide you with a complete suite of services to make DevOps easier and smoother for your teams.
And the other one,
If you want to get that dream job, stop looking anywhere else. With the simple, straight-forward and easy to learn DevOps principles, you can learn how to manage a firm and you can earn yourself a certificate to brag about it as well, want to get started?
Can you deduce which of the firms, would more likely make which statement? That depends on what they want you to think of DevOps as. A software firm that has to sell its product to software engineers, would likely demonstrate it as a tough product. On the other hand, those who want to lure the software engineering students to learn about DevOps would like to tell them, that, it's okay to be scared, but DevOps is simple.
The DevOps term is a wordplay on the development and operations teams. Which emphasizes on the active collaboration of the development and operations teams. In a broader sense, it also engulfs the customer relations, quality assurance and documentation teams because the entire process has to be transparent and open for every team in the process.
There are many other similar terms that have originated such as,
And much more, and they all focus on the same one thing: Enabling the collaboration within teams. In the next sections, I will explain more on these concepts and will try to build the concept around real scenarios — one more thing, there will be no sugar coating, and thus you will know what to expect. 😃
The DevOps workflow is a complete suite of software development approach and model. This is one of the reasons why I did not try to solve the problem inside the Agile or any other SDLC models and provided DevOps with a complete area of itself. DevOps is a parctice that enables developers to do more, requirement analysts to do what's right and operations team to manage correctly. The process engulfs the overall planning, development phases and deployment management. The focus is also on special products and toolchains that enforce DevOps principles.
The steps which become prominent in other model may be shrunk in order to provide more space for the important parts of an SDLC — such as customer feedback, understanding and reasoning.
DevOps practices also ensure that the team is not wasting time on something that has less importance, and the team is capable of managing the product in its development, maintenance and shipping stages — thus the merger of Dev and Ops. There are several software development products available on the Internet that you can use, a few of them are,
If these products sound like they somehow automate your processes, then it might be understandable that you confuse DevOps for automation. But DevOps is not just automation of processes, but of entire environment and mindsets. The workflow for the products release is open to the developers as well as the operations team. In the development cycle I will give an overview of how the software updates are managed by the automated tools and trigger a software update.
This workflow allows teams to not only work better, but also allow them to rapidly solve the problems in the product that are preventing the next release to be shipped.
The cycle itself is not different, infact it is similar and identical. However the inner definition of the stages is different. DevOps not only requires the phases to be agile, but it also requires the tools used to be following the same automated practices and must be intelligent). Without further chatter, let us quickly have a look at the phases as they are implemented by DevOps. You can contrast them against the Agile, Waterfall or Iterative models and look for what traits have been captured from where. 😃
The planning phase, like all other models, includes the ways to understand the product. But unlike Waterfall or V-shaped model, the planning phase in DevOps is flexible and can be changed/reconfigured after your development phase starts.
The planning phase is the one where you must discuss the requirements — if you have read other parts of this website, then you must know how much I hate the testing phase and how much I put emphasis on the requirements analysis.
The requirements of the product are discussed and put forth by the stakeholders, customers and end users (if introduced). There are so many terms such as user-stories, features and much more that I would discuss in the glossary later. For now, the requirements phase ends up with the overall sketch of the product, its features and what it is expected to do after each release.
There are different tools provided for this phase, the tools that help your teams better draft out the most important parts of a software and leave the unimportant features and services to a later release.
The development phase as the name suggests is meant for the development of what is designed, drafted and decided to be released in the requirements phase. The development phase takes place on the requirements phase and builds the software. Software developers, engineers and architects come together to write the piece of code for that software. Like iterative model, DevOps encourages an incremental and iterative approach at writing the software.
There are many tools that adapt to these practices. Visual Studio Enterprise is one of such a software development tool that comes shipped with DevOps toolchains, ranging from development, debugging, testing and releasing the product.
The development in DevOps environments must be defensive. The defensive programming asserts that the code must take into consideration all scenarios in which it may break. This single step reduces the need of a separate test suite to be created for the code resilience check. In many cases, the defensive programming can properly eliminate the requirement of testing at all. However, too much of defence can also kill the ability of a program to tell the user, that it is time to quit. It is up to you as the software engineer to better understand when to be more defensive and when to be aggressive.
The term coined here is the Continuous Integration, in which, the changes applied to a code repository are reflected in a new build artifact. Each time a new change is applied to the repository, a trigger happens and the code compilation takes place. There are different ways of configuring and setting up the CI, each depends on several factors such as,
And much more, I will walk you through these steps as well, later on.
Testing is the logical aspect of debugging and ensuring that the product does what it is expected to do. There are several testing packages available that adhere to the DevOps principles. Such as the Live Unit Testing available in Visual Studio IDE.
The testing must be done on the basis of functionality, and not the code compilation, or code running. This is one of the primary differences in DevOps testing, and the testing for Waterfall and other non-flexible models.
Release phase is further categorized under packaging, deployment and updating the software packages where the software has been deployed and installed.
Like mentioned in the development phase, the software is packaged and after each successful build, a new package is built as a build artifact. That artifact has likely everything to run as a package, it has,
This build artifact is kept for further testing as needed. Most of the times, software has been published and it works as expected, however the software no longer adheres to the policies and requirements of stakeholders. In such cases, the software must be peer-reviewed before being published to the production environment. Once the release is ready to be published, the software then published the build artifacts to the common server, from where the users can download the app.
This is where the counterpart for the Continuous Integration comes in, the Continuous Deployment. Continuous Deployment suggests, that each time a CI succeeds and a build artifact is available, system must trigger a notification for software update or automatically try to update the installation.
All of this is possible because of automation in services/toolchains which is supported and encouraged by DevOps.
One more thing, the DevOps principles only encourage the build artifact publishing. They do not prevent someone from publishing the app to anywhere. Which is why, most of the teams have welcomes DevOps practices because it lets them publish their own apps from the source code, all the way up to the stores. You can publish,
And much more. The flexibility is available due to the automation of the tools. This demonstration can be given once I provide the VisuaL Studio Team Services introduction and tutorials.
The monitoring of the products means that you monitor the product through various tools and products, and update your backlogs for the next iteration. The monitoring of the product is an on-going step and mostly inclined toward the Ops part, but the Dev also play an active role in understanding how the product is working, how the users are using it and how the product must behave.
There are several products, depending on the type of product you have.
And others, in the marketplace for the tracking of bugs, resolving them and understanding the influence of each bug in the application.
The DevOps benefits are huge, but they are all hidden somewhere behind mountain, which is tough to climb for most. The DevOps learning path, and the environment setup requires a lot from the organization, teams, and everyone involved. The results are that the overall collaboration, transparency and commitment within the teams to better understand, develop and monitor the products, is increased, thus producing high quality services and enabling more communication with the customers and stakeholders.
I do not have the compiled survey reports for DevOps, but I try to dig in and ask for further permissions from their respective owners before publishing the benefits here — if you have a survey report, or are an owner of a published report and would like to share, let me know.
Other methods might also have some of their own benefits, such as Agile methodology, or Iterative methods support iterative development and incremental build systems. In no way am I suggesting that DevOps is a universally accepted and must-supported methodology, the only concern I have is that it provides more flexibility to the development and management of the product as compared to other models. For a reference to other models, please read their own respective guides.
Sadly, this chapter does not have any topics to share.