François Desrosiers

As the saying goes, it’s not about the destination, it’s about the journey. The same could be said about DevOps and its implementation in an organization. Yes, the result is magic since it aims to deliver daily business value, but the journey is even more interesting. This journey is full of organizational, technological, but especially human discoveries.

Comme dit le dicton ce n'est pas la destination, mais la route qui compte. On pourrait dire la même chose pour DevOps et de son implantation dans une organisation. Oui, le résultat est magique puisqu'il vise à nous faire livrer quotidiennement de la valeur d'affaires, mais le périple l'est d'autant plus. Ce périple est rempli de découvertes organisationnelles, technologies, mais surtout humaines.

Pour avoir un aperçu de la perception et compréhension des personnes de quelque chose, il suffit de regarder les réseaux sociaux.

To get an insight into people's perception and understanding of something, just look at the social networks. This message coming from a company looking for a lead DevOps makes me ask myself a big question about the perception and understanding of the market about DevOps. But is DevOps really a person with that role in the organization? But first of all, what is DevOps? According to Wikipedia, here is the definition: “A cultural and professional movement that stresses communication, collaboration and integration between software developers and IT operations professionals while automating the process of software delivery and infrastructure changes “ Essentially, here is my understanding and interpretation of DevOps, It is a practice that aims to bring mutual empathy to two groups, the Dev and Ops, who have goals that go against each other. Thus, the application of the DevOps practice will allow the achievement of the objectives specific to each group while respecting the responsibilities of the other. I mention two teams when ideally, it should only make one, but unfortunately historically and even today these are two distinct groups that do not have the same goals. One is to deliver business value as quickly as possible while the other is to have the most stable infrastructure possible. Now, to make it work it takes two things, firstly there needs to be a framework to structure the business value delivery process, for example Scrum or Kanban. The agile approach chooses, will allow the entire organization and development teams to produce value-worth each iteration even every day. Secondly, it is necessary to have a set of automated tools allowing the Ops and the Dev to follow the delivery rate of business value of the organization while respecting the objectives and responsibilities of each group. To maximize the chances of implementing a DevOps practice within an organization, it is imperative that the two basic criteria are present, a framework to structure the business value delivery process and a suite of tools. If the willingness to implement DevOps comes only from IT through tools, the entire organization will not be able to follow and see the initiative like an expense without real value. If the will comes from the organization and the agile delivery train and the IT team does not have the necessary knowledge and tools, implementation of the practice will put a lot of pressure on the organization, it will not have the expected successes. So a first step is to set up a framework for structuring and guiding the value workflow, for example Scrum or Kanban. With a good application of Scrum or Kanban, the organization will be able to support the frequent or even daily deliveries of the customer's need from its realization to its delivery. On the other hand, to be able to implement a DevOps practice, it is necessary that the business value delivery process has reached a certain level of maturity throughout the organization. What I mean by that is that usually when an organization decides to take the agile turn with Scrum or Kanban, the application of the framework only sticks to the development team. With the team's growing maturity with Agility, the team expand the reach of Agility by including business side and IT operational. This is when the organization can more easily implement DevOps practices in its Dev and Ops teams. On the other hand, it’s possible only if they have the right tools, which leads to the second criterion. This is why it is essential that teams have a toolbox containing all the tools to achieve these objectives. Usually, one or more tools will need to be found for each of the following categories: Version control and artifact repositories Continuous Integration/Continuous Delivery Quality check Automated testing tools including static code analysis checkers automated test frameworks performance testing tools Automated release/deployment tools Infrastructure as Code: software-defined configuration management. Virtualization and containerization technologies If I go back to the beginning with the Linkedin's post of a company looking for a lead DevOps, as we see it is not possible that only one person, or even a group, is responsible for the DevOps practice. So if you want to set up a practical DevOps in your organization, make sure you have both essential criteria in place and especially empower the entire organization rather than a team or person.

Comme on l'a vu durant la présentation, l'Agilité a des impacts à tous les niveaux et touche même les bases de données. Pour être capable de travailler efficacement dans un contexte Agile, le DBA doit ajuster sa manière de travailler autant en conception, que durant la réalisation ainsi qu'au moment de déployer l'application

Recently discussing design and programming with an external programmer, he explained me his approach of defensive programming. But before going in detail of his explanations, Wikipedia help us to define the defensive programming: Defensive programming is a form of defensive design intended to ensure the continuing function of a piece of software under unforeseen circumstances. The idea can be viewed as reducing or eliminating the prospect of Finagle's law having effect. Defensive programming techniques are used especially when a piece of software could be misused. We understand that it is one "mind set" which is excellent, because it allows us to deliver less fragile code. Furthermore, this way of seeing things is in direct link with the creation of unit test (the TDD or TLD (Test Last Development) but I will not go into this debate here? J). Here is an illustration of its vision (of the developer) The developer explained me that it is essential to put of the management of exception in Service123 but also in all the functions of all the classes of the utilitaire assembly. Also, that it was imperative to put some validation of parameters everywhere, but also in the classes marked as internal, thus not visible and usable from everything outside of the assembly which contains them. It is at this moment that I said to myself: "Can the defensive programming in its limits can quickly become of the paranoiac programming?" I give some explanation, the try catch and the validations have impacts at several levels among which on the performance and the code’s readability to name only these. I, above all I try to identify the entry points of my components which can bring irregularities in the functioning of my system. Also, I try to identify the places where I have a dependence towards contexts outside my application (Web service, database, physical file) because these dependences can weaken my component or class. The rest I trust my unit tests to validate my non-regression and the smooth running of the features of my classes. Thus if we return to our example, the entry points of this micro-system are ProduireDoc of Service123 and CreerPatente of the ComponentA class. These two places should validate their parameters. Since, Service123 depends on ComposanteA thus, then Service123 should manage exception for various reasons (masking interne exception, management client’s experience, logging, etc.). Then, the function FaitXYZ of ComposanteB should not make validations on what the component ComposanteA passed as parameters but only the validations of the logic that it takes care and it’s the same thing for the exceptions, it should be captured by the entry point CreerPatente of ComposanteA. And you, how do you manage your programming, are you more a defensive or paranoiac type?