DevOps: Our feedbacks on the implementation



In 2014, after several departures, I had the opportunity to be promoted as the products team technical manager at Negotium technologies.

At that time, the situation was not the best, we were flooded with support. Many were criticizing quality and only a few things were automated in the firm.

Throughout this article, I share the feedbacks of our journey in the establishment of automation and continuous delivery process. In almost 2 years, our team has grown from 2 to 11 individuals and we do not deal with 2 products/servicesnow, but 5.

Get our head above water

Initially, the source code control server was crashing regularly (an old TFS 2010), the releases sent to customers were made on a developer station and our processes were poorly documented.

The team was ill-equipped, so we were losing a lot of time!!!

Therefore, the first step was to graphically represent our operating processes, to apply them correctly and improve them continuously.

The next step was to equip ourselves properly for our “basic needs”. So we migrated to ¨Visual Studio Team Services¨ (see my blog about it) and setting up a cluster System Center to build independent environments as requested.

This gained time, because we no longer waiting after the source code control or after environments, which is approximately 4 hours’ week/developer, has been invested in increase in production improvements in our methodologies.

Give ourselves the ability to anticipate

At that time, Jean-François joined the team and we have decided to put back in place ¨Scrum¨ within the team. There is a lot of documentations about this subject, so I assume that you have knowledge about basic methodological principles

A biweekly planification and the formalisation of the job, have allow us to increase our productivity: less reunions, less interruptions and more concentration.

Furthermore, Visual Studio Team Services already provides full support of the methodology Scrum, therefore we do not need to add a tool because we already had it.

What is important to understand, is that the continuous delivery and DevOps processes rely on the fact that the delivery framework is iterative.

Having to plan several sprints brought something else in products, which is the obligation to have a clear roadmap, and therefore a solid business case on products. We knew then in which directions the respective products were going and that they had a definite budget. (really important for the C-level)

Enlarge the family

Early 2015, Negotium acquired Pollen (see press release on the subject) which allowed us to expand the team passing gradually from 3 to 10 individuals with the arrival of Yann, Quentin, Benoit, Pascal et Sébastien.

Several issues were raised at that time all related to the same question: how to industrialize production value from an idea?

Formalize Scrum

First, we needed to ensure that everyone knew their role in the structure and responsibilities to get to work together and without discord.

Quentin became our scrum master and guides the POs to ensure that they provide something digestible for the team. He also supports the team to ensure that it gets to move smoothly.

We named several Products Owners, it is they who are responsible for the commercial and functional product development:

–          Jean-François for Oceanik

–          Nicolas for Bizdesk

–          Yann for Radar

–          And our partner Coginov for Attribute

Cloud first approach

Having a cloud first approach, to comply with good practices associated and to implement the recommended patterns (microservices, containerization …) allows us to abstract ourselves from issues of bounce back after failure, increase in load and to focus on our added value.

Reduce friction

Now, we have a larger number of developers. Consequently, we need to ensure that the work in parallel and/or asynchronous will not cause any integration problems and will not be too expensive to manage.

On Yann’s suggestion, we went on a process flow git for Branching (supported by git, hosted on Visual Studio Team Services). This was clearly a success reducing complexity and the integration time. (see resources on this topic)

Automate as much as possible

When you lose 30 minutes per week per developer and that we are only two developers, it is not that bad. But when you are 11 it represents a lot of time.

We quickly realized the need to automate as much things as possible. First, it was only simple powershell scripts to reach today full operational industry software with build, test, deployment, configuration and modifications (scale, failover…) automated.

Indeed, there is an initial cost, especially when the team needs to discover it but earnings are well above the completion time of the task by hand.

Because it is automated, we are not afraid to do it more often and as much as possible. This allows for a return of almost immediate information on the change made and to react accordingly.

To illustrate my point, I will take one example among many others:

When one of the team members today make codes because he believes he have completed a feature, automatically and without any clicks from him, the system compiles (and performs any actions to pass from the code to deliverable) and test. (then deploys, the QA start…)

While this process takes place, he is free to do something else and get the result as soon as it’s over.

He no longer needs to wait for the monthly build where we hope nothing is broken (but we don’t know that) for feedback on our code.

The quality manager

Finally, last September, we had the opportunity to integrate Ahmed to our team as Quality Manager. Someone who has a quality assurance training brings a lot to the team. His arrival has empowered developers (more of that build so it works), brought a lot of our people to see things in a different way to ensure in the end that the existing problems are known, and that the least possible problems arrive at customers etc.

The big problem that we have had to confront when he arrived was to increase quality assurance. Suddenly, we were no longer able to deliver new releases because they did not pass the quality phase.

Obviously this phase of overall improvement in the quality and product reliability resulted in a reduction of the use of the support and better control of the medium-term support.

Next for us

The future in our case is:

–          Continue to integrate new members in this family

–          Add other products and services to our portfolio (stay tuned!)

–          Automate aspects of code quality

–          Implement a containerization strategy to facilitate and standardize deployments already largely automated

Additional resources

DevTeach Montreal 2016 – VSTS Devops




This Post Has One Comment

  1. Nice Article. In short description good explanation about the DevOps. Thanks For sharing the informative news.

Comments are closed.