De nos jours, le modèle “Devops” attire de plus en plus mais se conçoit à travers de nombreux changements. Le fait de vouloir intégrer rapidement de tels changements peut se solder par des échecs et une frustration décourageante.

Retour d’expérience d’une transition DevOps dans un contexte à fortes contraintes techniques et humaines.

De nos jours, beaucoup d’entreprises se transforment et adoptent la culture DevOps. Les bienfaits de cette transformation semblent aujourd’hui faire partie des faits établis. Cependant, bien que de nombreux articles en parlent, mener la transformation n’est pas toujours simple.

En informatique, coexistent de nombreuses technologies. Dans tout cet écosystème, il y a des technos qui naissent, d’autres qui meurent, mais il y a surtout des technos tellement hype et funky que passer à côté est un exploit à part entière.

Je propose une méthode concrète, mais pas forcément simple, pour parvenir à mettre en place dans votre équipe des bonnes pratiques tel que le « Code review », les tests, une CI (« Continuous Integration ») et une CD (« Continuous Deployment »).

Dans le précédent article je parle de la production et de ce que cela implique de s’en occuper. Mais quels rapports avec les termes DevOps et SRE ?

Je ne prétends pas pouvoir donner une définition claire et universelle pour ces mots mais j’aimerais pouvoir les démystifier et en rendre la compréhension plus accessible.

Aujourd’hui dans Dev’Obs on parle déploiement, bonne écoute.

C’est l’été, beaucoup de collaborateurs sont en vacance, vous êtes peut-être vous-même en vacance. De notre côté on en profite pour expérimenter des formats plus court et plus léger.

On me demande souvent ce que je fais dans la vie et je n’arrive pas à répondre.

Non pas parce que mon travail est flou, mais parce qu’il repose sur des concepts que la plupart des gens ne maîtrisent pas.

On entend souvent parler de « tests automatisés », de « pair programing » ou encore de « mises en production automatisés ».

C’est toujours si simple chez les autres.

Les « dev » et les « ops » se livrent une guerre depuis que le monde est monde ! Le clan « dev » n’arrive plus à comprendre les rouages de ce terrible conflit. Il est temps de rétablir la vérité vrai

We often hear about great organization with multiple teams, where everyone can talk to everyone else and every piece of information is accessible. We can hear about pair programing, code review, CI or CD.

Yeah, all of this seems so great, but this is happening in other companies. What about my team ? How can I use all of this for our project ? And men, what the hell is a CI ?

Using GIT every day is quite normal for a developer. We work with GIT, we trust it to keep our files safe and we trust it to share them too. A long time ago, when I was on my first internship at Easter-eggs I wrote a small web service to automate a customer’s GIT workflow.

I wrote about my Peak phone a while ago. It’s time to write again on FirefoxOS !

At work, we have a lot of project. Different part of many solutions developed for many customers. As an example, Comarquage, a solution I have to maintain contains following sub-projects :

Since I started to work in a company, I keep receiving more and more emails days after days… And I know I’m not the only one.

When I’m showing code or asking for advice to a colleague, I’m always surprised by their reactions when they see my jump function.

About a year ago, I left my Nokia N900 phone to buy a Geeksphone device ( Peak ). This was hard, very hard… and it still is.

At Python and WSGI for web applications development.

It’s been a long time since my last post. I’ve been through some difficulties in my professional life and that’s why I didn’t had time to worry about my Rasberry Pies.

The first step in making my own space on Internet with RPi is storage.