DevOps – A Modern Approach to Software Delivery

Technology has evolved over time. And with technology, the ways and needs to handle technology have also evolved. Last two decades have seen a great shift in computation and also software development life cycle. The key to quickly fixing delays in software development lifecycle lies in establishing a unified approach to IT development and operations, called DevOps.

Many companies over the years have accumulated a part-cloud, part-legacy, multi-vendor IT hodgepodge that needs to be addressed first. Old-school IT development offers a clear separation between development and operation teams in terms of skill and engagement. Modern IT, however, relies on merging the two, creating a new path known as DevOps. An engineer on this merged path will be capable of not only writing code and deploying it, but also running it, fixing problems, and providing analysis.

In this article, we are going to talk about DevOps, Challenges DevOps solves, DevOps practices and benefits. We will also discuss about the processes to be followed and how DevOps is the future of Enterprise IT.

What is DevOps? Evolution of DevOps

Communication, collaboration and integration are the three main principles of the ever-growing, modern approach to software delivery known as “DevOps.”

To make things clear — DevOps is a methodology. The idea of this methodology is to create a new mindset. A mindset when developers and operations combine their efforts to achieve a common goal.

Sometimes it is mistakenly confused with a tool or a role. It’s not a tool although it uses a toolchain to automate software delivery and deployment. Nor it’s a position although both operations and developers are expected to extend their responsibilities.

DevOps is the combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity: evolving and improving products at a faster pace than organizations using traditional software development and infrastructure management processes. This speed enables organizations to better serve their customers and compete more effectively in the market.

DevOps is a combination of the two words “development” and “operations.” Patrick Debois, a DevOps expert, came up with the term “DevOps” in 2009 and it stuck ever since. Some people say that it was around this time that there was a shift in IT culture, and DevOps represents this shift. DevOps is really an umbrella term that describes the operation of a team collaborating throughout an entire programming production process — from the design through the development stages. It’s a combination of tools and philosophies that increase a team’s capability to produce results at high efficiency.

Challenges DevOps Solves

Prior to DevOps application development, teams were in charge of gathering business requirements for a software program and writing code. Then a separate QA team tests the program in an isolated development environment, if requirements were met, and releases the code for operations to deploy. The deployment teams are further fragmented into siloed groups like networking and database. Each time a software program is “thrown over the wall” to an independent team it adds bottlenecks. The problem with this paradigm is that when the teams work separately

Dev is often unaware of QA and Ops roadblocks that prevent the program from working as anticipated.

QA and Ops are typically working across many features and have little context of the business purpose and value of the software.

Each group has opposing goals that can lead to inefficiency and finger pointing when something goes wrong.

DevOps addresses these challenges by establishing collaborative cross-functional teams that share responsibility for maintaining the system that runs the software and preparing the software to run on that system with increased quality feedback and automation issues.

DevOps is the extension of Agile Methodology

Back in 2009, more IT professionals started to move away from the traditional waterfall method and embrace nonlinear agile methodology by making each development stage independent and incorporating continuous testing early on and throughout the development cycle.

Consequently, this approach enhanced efficiency and reduced risk by allowing developers to make immediate changes before shipping to production based on the continuous feedback they received. While agile methods had always enhanced development, there was still a discrepancy in the flow when it came to deployment, which still embraced the waterfall methodology. While development used agile to lower risk and increase efficiency, deployment hung on to the linear waterfall structure, slowing down delivery and leaving testing to the end of the process — a process that wrongfully split ownership. This created huge bottlenecks in delivery cycles because developers would need to start from the beginning if a problem were discovered near the end of deployment.

It was through seeing this disconnect between development and deployment as well as understanding the benefits of embracing agile in all aspects of software delivery that Debois came up with the notion of DevOps. The marriage of development and operations along with the extended best practices and principles associated with agile had the potential to greatly increase efficiency and lower delivery risks.

Benefits of DevOps for your Organization

Companies that incorporate DevOps practices get more done, plain and simple. With a single team composed of cross-functional members all working in collaboration, DevOps organizations can deliver with maximum speed, functionality, and innovation.

There are technical benefits:

Faster resolution of problems

Less complexity to manage

Continuous software delivery

There are cultural benefits:

Happier, more productive teams

Higher employee engagement

Greater professional development opportunities

And there are business benefits:

Faster delivery of features

More stable operating environments

Improved communication and collaboration

More time to innovate (rather than fix/maintain)

DevOps Practices Explained

There are a few key practices that help organizations innovate faster through automating and streamlining the software development and infrastructure management processes. Most of these practices are accomplished with proper tooling.

One fundamental practice is to perform very frequent but small updates. This is how organizations innovate faster for their customers. These updates are usually more incremental in nature than the occasional updates performed under traditional release practices. Frequent but small updates make each deployment less risky. They help teams address bugs faster because teams can identify the last deployment that caused the error. Although the cadence and size of updates will vary, organizations using a DevOps model deploy updates much more often than organizations using traditional software development practices.

Continuous Integration (CI)

Developers integrate code into a shared repository multiple times a day and each isolated change to the code is tested immediately in order to detect and prevent integration problems.

Continuous Delivery (CD)

As an extension of CI and the next step in incremental software delivery, continuous delivery (CD) ensures that every version of the code that is tested in the CI repository can be released at any moment.

Continuous Deployment

Continuous deployment can be thought of as an extension of continuous integration, aiming to have a new code deployed in production to be used by live users. Supported by CI, when tests meet the release criteria, it is released immediately.

Configuration Management (CM)

In a nutshell, the process of maintaining up-to-date, detailed records of hardware and software — including versions, requirements, network addresses, and design and operational information — is known as configuration management (CM). You can use CM tools such as Chef, Puppet, or Ansible to aid the process. You can also use Bash and Python to build your own configuration management automation.

Bug Tracking

A bug tracker is a system that aggregates and reports software bugs and defects. It helps R&D organizations with task management and is part of the consistent feedback loop that the DevOps methodology requires.

Test Automation

Test automation facilitates test engineer work by supporting multiple tests that run continuously. It enhances test coverage while supporting efficient release cycles. For example, test automation tools help manage, execute, and measure functional tests and load tests.

Unit Test

Unit testing is a process that allows testers to examine small parts of an application, such as a specific code or module. This test is usually automated and reused in order to support continuous testing and integration.

Monitoring and Logging

Organizations monitor metrics and logs to see how application and infrastructure performance impacts the experience of their product’s end user. By capturing, categorizing, and then analyzing data and logs generated by applications and infrastructure, organizations understand how changes or updates impact users, shedding insights into the root causes of problems or unexpected changes. Active monitoring becomes increasingly important as services must be available 24/7 and as application and infrastructure update frequency increases. Creating alerts or performing real-time analysis of this data also helps organizations more proactively monitor their services.

TechnoGems Processes in adopting DevOps Model

The DevOps model relies on effective tooling to help teams rapidly and reliably deploy and innovate for their customers. These tools automate manual tasks, help teams manage complex environments at scale, and keep engineers in control of the high velocity that is enabled by DevOps. AWS provides services that are designed for DevOps and that are built first for use with the AWS cloud. These services help you use the DevOps practices described above.

Normal Development of new features (Hotfix Process)

The below process describes the flow for regular features. Most of the time this is the process we should follow (i.e.) from the development branch

Step 1: Create a new feature branch for the JIRA task and commit the change.
Step 2: When done, create a pull request and merge the change to Development.
Step 3: When the pull request is merged, the code will be automatically deployed to development server.
Step 4: When we are ready to deploy a release, create a pull request from development to release branch.
Step 5: When the code merged to the release branch, the code will be automatically deployed to the staging server. These points to the production database, so care should be taken when testing here.
Step 6: If we find any defects in staging, create a Hotfix branch from the release branch and make the code change.
Step 7: Create a pull request to merge the change to release branch which will trigger an automatic deployment to staging server. Once tested, create another pull request from this Hotfix branch and merge it to development branch. This will trigger an automatic development to dev server.
Step 8: When customer is satisfied and we are ready to move to prod, create a tag on the release branch to signify the production launch. Then merge the code to the master branch. There is no automated deployment based on master branch. Then go to the AWS code deployment and approve the code deployment to deploy to production. This can be done from the AWS console. This will deploy the last version that is deployed in staging to production.

These are some key items to consider and follow during the development process

Feature branches should be names as feature/MS-nnnn where MS-nnnn is the name of the Jira ticket.

Before creating a pull request, always pull changes on the development branch to your feature branch. This allows you to resolve any conflicts in your local machine and merge the changes to development smoothly.

Hotfix branches should follow hotfix/MS-nnnn as the branch name. MS-nnnn is the original Jira ticket or the new ticket if this is a new defect identified.

When tagging production release, use the naming convention prod-release-YYYY-Mon-DD-n (eg prod-release-2018-Jun-24–1 to mark the first release we did on June 24th. If we had another release because of some emergency, the number will be -2 at the end).

Out of Cycle Emergency (Quick fix process)

The below process describes the flow for emergency quick fix.

When the customer request emergency or quick fixes while we are working on a release, we need to follow the below variation. The process is similar to the Hotfix process above with one key difference.

Step 1: Your Hotfix branch from the latest production tag and commit your change. At this time, go to the commit in Bitbucket and select run code pipeline. This will generate the release version of the file to the S3 bucket. This triggers a code pipeline on the AWS side and it will deploy the code to staging. (Please note that this will overwrite any future changes in staging and that is fine.).
Step 2: At this point the staging server has the production code plus the Hotfix. After testing the code, approve the code push in AWS and it will deploy to production.
Step 3: After the fix is deployed t production, merge your Hotfix branch to release branch. This will re-deploy the code to staging with the new Hotfix and any previously deployed code in staging. The Hotfix should also be merged to development branch so that it will be there in all environments

Comparison between SDLC, Scrum, Agile

SDLC	Agile	Scrum
Software Development LifeCycle (SDLC) is one of the oldest concepts for software development, describing the sequential development phases.	Agile is a development methodology based on iterative and incremental approach.	Scrum is one of the implementations of agile methodology. In which incremental builds are delivered to the customer in every two to three weeks’ time.
The main characteristics of the SDLC method are the division of the project into tight compartments, reducing the dependency on individuals in the team.	In the Agile process the leadership plays a vital role.	Scrum fosters a self-organizing, cross-functional team.
More Documentation is required and it does not accept any changes in the customer requirement.	The biggest advantage of agile is its flexibility as it quickly reacts to changes.	Compared to Agile it is a more rigid method. So, there is not much room for frequent changes.
The main characteristics of the SDLC method are the division of the project into tight compartments, reducing the dependency on individuals in the team.	Agile involves collaborations and face-to-face interactions between the members of various cross-functional teams.	In Scrum, collaboration is achieved in daily stand up meeting with a fixed role assigned to scrum master, product owner, and team members.

Conclusion

DevOps is how IT gets done in this Digital World. A lot can be achieved in the right implementation of DevOps, making the production of apps more effective, saving time and money, while increasing quality and time to market.

By implementing a DevOps approach, you will be able to reduce significantly, the costs and demand for resources associated with traditional IT implementations.

Traditionally, IT was seen as a cost center but the implementation of DevOps has shown that this approach provides real business value. When you use continuous delivery and lean management practices, you get higher quality results and shorter cycle times, further reducing costs. These practices contribute to reducing the resource requirements in terms of both manpower and hardware. A modular architecture consisting of well-encapsulated, loosely coupled components allows organizations to make efficient use of cloud computing.

We at TechnoGems help to reduce cost and resource requirements include minimal project start-up and ongoing operating costs, increased collaboration, increased data availability and accessibility, and improved security. Contact TechnoGems to modernize or build your app by emailing inquries@technogemsinc.com

Related Post