DevOps

The merger of Development (Dev) with Operations (Ops), DevOps, is the natural follow-up to Agile. The first principle of the manifesto for agile software development^[1] already made it clear that “our highest priority is to satisfy the customer through early and continuous delivery of valuable software“.

This seems a neutral and universally valid proposition until we realize how distant it is from the current practices of organizations.

The relationship between information technology (IT) and operations (the business) has never been peaceful. Represented by internal information systems departments or external vendors, traditional IT (pre-DevOps) has taken on unobtrusive positions, taking a long time to respond to the aspirations of the areas using its solutions. And the operational areas tend not to transfer their knowledge of processes and practices to IT since most of the times traditional IT does not appreciate and react negatively to these suggestions, which it considers “excessive” customization ^[2].

In the continuous flow of customer value creation, much better collaboration is required between the many functions involved, that is, a process reengineering that also includes IT.

DevOps advocates the constitution of joint and direct teams, jointly and severally responsible, without the intervention of third parties.

The commonly called third parties (Quality Assurance ^[3], coordination, a project oversight) to create a bridge between Dev and Ops in practice destroy the new trust that the DevOps culture wants to institute between development and operations. And they destroy, inevitably, because their only reason for existence is the assumption that this trust is absent ^[4].

In the DevOps culture, the software development organization is no longer by design, but as a continuous service that

• detects (and even anticipates) new customer needs and models new requirements.

• converts these requirements quickly and immediately into code.

• integrates, tests and ensures the consistency of all the components and the work developed in parallel by several teams.

• delivery or makes the new version available to the customer.

• (on request or after validation) puts the new version in productive use by business/operations (Ops).

The DevOps community, very strong, organizes every year the All Day DevOps, an event that surely is worth following. While it does not arrive in 2018, it is worth watching the 100 sessions of 2017 ^[5].

Puppet’s report on the current state of DevOps (2018 State of DevOps Report)^[6] is also a useful reference.

The contribution of Quidgest

Genio is a decisive factor in ensuring the automation of this entire process.

Without Genio, DevOps suffers from one of three limitations

• only starts with continuous integration and does not include the exploration phase of new requirements.

• or have no way to model these new requirements.

• Or, between exploration/modeling and continuous integration, a considerable manual programming effort is required, with manual programming throttling the DevOps stream and ultimately deteriorating its intended results.

DevOps flow may be slower or maybe faster. Being speed, of course, is the most desirable goal and the competitive advantage to be achieved. It is of little use to say that one adopts this perspective if the availability times of versions improved by the development (Dev) to the operations (Ops) remain very long.

Genio contributes decisively to the success of this perspective by linking the whole process:

• models the requirements.

• program automatically and extremely fast code.

• integrates the work of several teams (through GenioSVN).

• prepares, tests, and delivers (through open-source tools like Jenkins, which Quidgest can use, unlike other platforms, for using only standard programming languages).

• ensures the automatic evolution of the data structure and documents, reports and prepares end users to ensure productive use of the new version of the solution.

DevOps requires the existence of architecturally significant requirements. At Quidgest, these requirements have been transformed into standards, constituting the set of standards related to software engineering.

The integration process requires a version control tool (in Quidgest, GenioSVN), with all the functionalities associated with repositories, checkouts, baselines, updates, commits, conflict management, list of changes, branches or forks, peer review and accountability (blame).

Genio supports another very important aspect: the business model (data structure, business rules, interfaces, and processes) and technology (architectures, programming languages, libraries, standards). These two layers ensure the continuity and integration of the entire process.

In a process of continuous integration, evolution is also continuous. This guarantees 1) much longer useful life of solutions and 2) non-existence of disruptions due to the change of versions of the software.

Our customers and partners in co-innovation, in particular, the ones we awarded this year, are a good example of the practical application of DevOps to large management systems.

___________________

[1] http://agilemanifesto.org/principles.html
[2] A revista QuidNews nº 10 ilustrava, com uma pequena história “O aleijadinho e o alfaiate”, a páginas 25, o que a Quidgest pensa deste conceito de excessiva customização.
[3] O diagrama que, a esta data, ainda figura na página wiki correspondente https://en.wikipedia.org/wiki/DevOps#/media/File:Devops.svg ainda inclui o QA na equação, o que não nos parece fazer qualquer sentido
[4] Uma posição muito próxima é defendida por Asaf Yigal https://devops.com/devops-killed-qa/
[5] Disponíveis em https://www.alldaydevops.com/2017-all-day-devops-video-recordings Por exemplo “It’s Not Continuous Delivery If You Can’t Deploy Right Now”, por Ken Mugrage
[6] Acabado de publicar, a 12 de setembro