DevOps

DevOps is a set of processes, methods and systems for communication, collaboration and integration between departments for Development (Applications/Software Engineering), Technology Operations and Quality Assurance (QA).

It relates to the emerging understanding of the interdependence of Development and Operations in meeting a business' goal to producing timely software products and services .

DevOps helps to enable Business Agility & IT Alignment by aligning Development and Operations roles and processes in the context of shared business objectives. Both development and operations team need to understand that they are part of a unified business process. DevOps thinking ensures that individual decisions and actions strive to support and improve that unified business process, regardless of organizational structure by avoiding conflict and inefficiency between Development and Operations activity in IT .

Companies with very frequent releases may require a DevOps awareness or orientation but DevOps is not just about developers collaborating with Operations team on deployment and releases. It's about both teams understanding each others responsibilities after code is deployed to production, and collaborating along the areas of their expertise in a way that's constructive. The whole point of DevOps is to enable your business to react to market forces as quickly, efficiently, and reliably as possible

DevOps is not a technology problem.Technology plays a key part in enabling solutions to DevOps problems. However, DevOps itself is fundamentally a business problem.The most fundamental business process in any company is getting an idea from inception to where it is making you money.

The adoption of DevOps is being driven by factors such as :

• Use of agile and other development processes and methodologies .
• Demand for an increased rate of production releases from application and business unit stakeholders
• Increased usage of data center automation and configuration management tools

Deployment automation

Deployment of a real world application is a complex and all-too-often manual process.
IT deployment instructions are typically found in multiple documents, spread across several groups and may be incomplete, requiring tribal knowledge in order to be executed successfully. Components of the application may need to be deployed in some specific order to any number of environments, from early testing, user acceptance, and staging, to production, performance, and disaster recovery. The manual deployment process must be repeated for each environment. We need insight into what is deployed where and an audit trail showing how it was deployed, what exactly was deployed, and who ran the deployment.

The DevOps Platform helps foster collaboration between development, IT and production support in the delivery pipeline, by allowing team members to perform tasks traditionally out of their scope, on demand. For example, after unit testing their code, developers deploy it to the next environment for further testing. DevOps removes the bottlenecks between traditional groups by automating the delivery pipeline and increasing efficiency.

Runbook Automation

RBA helps organizations by reducing manual tasks which are time consuming and also prone to human-error issues, provides a more efficient workflow through automation, and reduces operational costs while still meeting IT service levels and compliance.

Typically, a run book will contain procedures to start, stop, and monitor systems and networks. These procedures translate to processes such as mounting archival storage volumes at some predetermined scheduled backup period. This is the very essence of a workflow. Where scripts and schedulers address small, simple tasks, a run book can scale to handle complex environments. Run books also possess reporting facilities that enable operators to audit progress trails and verify process compliance.

Continuous Integration

Continuous integration (CI) is a set of practices intended to ease and stabilize the process of creating software builds. CI assists development teams with the following challenges:

Software build automation: With CI, you can launch the build process of a software artifact at the push of a button, on a predefined schedule, or in response to a specified event. If you want to build a software artifact from source, your build process is not bound to a specific IDE, computer, or person.

Continuous automated build verification: A CI system can be configured to constantly execute builds as new or modified source code is checked in. This means that while a team of software developers periodically checks in new or modified code, the CI system continuously verifies that the build is not being broken by the new code. This reduces the need for developers to check with each other on changes to interdependent components.

Continuous automated build testing: An extension of build verification, this process ensures that new or modified code does not cause a suite of predefined tests on the built artifacts to fail. In both build verification and testing, failures can trigger notifications to interested parties, indicating that a build or some tests have failed.

Post-build procedure automation: The build lifecycle of a software artifact may also require additional tasks that can be automated once build verification and testing are complete, such as generating documentation, packaging the software, and deploying the artifacts to a running environment or to a software repository. In this way artifacts can quickly be made available to users.

The system components come into play in the following sequence:

1. Developers check new and modified code into the source code repository.

2. The CI server creates a dedicated workspace for each project. When a new build is requested or scheduled, the source is retrieved from the repository into this workspace, where the build is then executed.

3. The CI server executes the build process on the newly created or refreshed workspace.

4. Once the build completes, the CI server can optionally invoke the defined test suite on the new artifacts. If the build fails, registered individuals can be notified by email, instant messaging, or some other method.

5. If the build is successful, the artifacts are packaged and transmitted to a deployment target (such as an application server) and/or stored as a new versioned artifact in a software repository. This repository can be part of the CI server, or could be an external repository, such as a file server or a software distribution site like Java.net or SourceForge. The source code repository and the artifact repository can be separate, and it is actually possible to use some CI servers without any formal source control system at all.

6. CI servers usually have some sort of console where projects can be configured and debugged, and where requests can be issued for operations such as ad hoc immediate builds, report generation, or retrieval of built artifacts.

Seemless deployment and five 9’s

By Seemless deployment we can ensure ensure Five 9’s and higher levels of operational performance will be guaranteed.