Unsupported content This version of the documentation is no longer supported. However, the documentation is available for your convenience. You will not be able to leave comments.

DevOps

DevOps is an emerging set of principles for communication, collaboration, and integration between software development and IT operations professionals (system administration and infrastructure). These professionals recognize an interdependence between the development process and the operations disciplines in rapidly producing software products and the processes that use them. This topic describes how DevOps can be beneficial to you:

Origin of DevOps

As organizations have adopted the agile software development methodology, that adoption has increased the number of releases. The increase in releases has resulted in increased pressure on release management teams, which, in turn, has resulted in stress on IT Operations professionals to track and execute complex application processes. The IT Operations teams use methodologies such as the Information Technology Infrastructure Library (ITIL) v3 Service Transition, which contains a section about release management that aims to improve release management capabilities. Agile methodology has driven Development and IT Operations teams to work more closely together during software release events. This trend of collaboration is referred to as DevOps.

DevOps principles target product delivery, quality testing, feature development, and maintenance releases. DevOps improves reliability and security, and shortens development and deployment cycles.

Reasons for using DevOps principles are as follows:

  • Use of agile development and the latest development processes
  • Virtual environments are used frequently
  • A demand for frequent and fast releases
  • Processes are automated, requiring less human intervention (for example, in data center and configuration management tools)
  • Development and Operations are required to collaborate more

DevOps aids the release of software

If you use DevOps, application release risks are likely to be reduced.

Reduced change scope

More and more organizations are moving away from the waterfall model of software development and adopting agile methodology or other similar methodologies, so they have frequent and multiple releases with fewer changes.

Enhanced software release coordination

You must use release coordinators to close the expertise and communications gap between Development and Operations. They can use various collaborative tools, including spreadsheets, messaging, intranet portals, wikis, conference calls, and so on. Full cooperation between them is necessary.

Automation

Deployment automation can ensure frequent repetition of deployment tasks and reduce deployment errors.

Adopt DevOps methods

Your organization might have separate Development and System Administration departments. A Development department concentrates on delivery of new features and features that might be required frequently. The System Administration department is more likely to concentrate on IT services and optimization of costs. This apparent contradiction in goals can slow down software delivery. Multiple issues are likely to arise:

  • Operations is not in the loop when Development considers code enhancements and delivery of new features.
  • Developers can lag behind in communicating configuration or environment changes necessary to run the updated code base.
  • Developers make changes in various configuration states, often without maintaining adequate documentation of all the parameters involved. After they reach a working state, they can have difficulty in recalling the exact steps necessary to achieve that working state.
  • Developers are likely to use systems or tool sets that ensure rapid and fast changes. Operations use systems that ensure stability and meet flexibility requirements.
  • A development environment often runs locally on the developers' workstations. In Operations, the system is often distributed among a web server, an application server, a database server, and so on.
  • Development concentrates on functional requirements, which are usually directly related to business needs. Operations is driven by nonfunctional requirements, such as availability, stability, performance, and so on.
  • Operations tries to minimize risk to delivery of nonfunctional requirements by avoiding change. Avoiding frequent change while the requirements for necessary change remain constant results in future change requirements becoming bigger.
  • The bigger the change requirement, the bigger the risk.
  • Operations tries to avoid change, which slows down the addition of new features to production. The cascading effect is a slowing down of Development's ability to deliver new features.
  • Operations is less likely to be aware of internal aspects of applications and might incorrectly define the runtime environment and update procedures.
  • Development might lack a comprehensive understanding of runtime environments while writing code.

Requirements for the development and release process

Following are the requirements for the development and the release process:

  • Defining more and smaller changes, which means less risk
  • Giving developers more environment control
  • Giving infrastructure more application-centric understanding
  • Clearly articulating simple processes
  • Automating as much as possible
  • Collaboration between Development and Operations

As organizations seek to streamline the transition or cooperation between Development and Operations, they typically confront the following types of problems:

  • Release management problems: Your organization needs more solid release planning tools than spreadsheets or similar tools. You want an easy way to understand release risks and dependencies, to stage gate adherence, and to ensure compliance.
  • Release and deployment coordination problems: You are focused on better execution of release and deployment events. You want better tracking of discrete activities, faster escalation of issues, documented process control, and granular reporting.
  • Release and deployment automation problems: Your organization might have existing automation, but you want to manage and drive this automation more flexibly. You might not want or need to enter everything manually at the command line. Ideally, the automation can be invoked by non-operations resources in specific nonproduction environments. You must prioritize by identifying which problem needs the attention first and put the problems in a definite order.

BMC Release Process Management as a DevOps tool

BMC Release Process Management software helps the release coordinator perform the following tasks:

  • Fill the Dev/Ops gap
  • Manage the increased infrastructure complexity
  • Increase the rate of releases in an agile and iterative development environment
  • Coordinate among distributed teams: globally deployed, outsourced and hybrid development, testing, and infrastructure teams

BMC Release Process Management focuses on planning and reporting on software changes so that you can control the release of specific application changes into production, which is a particular concern of release engineering. Release engineering is generally concerned with the systematic and technical work related to building and deploying code into environments.

 

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*