Pelisse Romain

Un peu plus d'une dizaine d'articles [2.1] ont précédé celui-ci dans ce magazine, et ont déjà amplement décrit des outils de gestion de la configuration de serveurs [1.1], tels que Puppet [1.2], Chef [1.3], ou même encore CFEngine[1.4]. L'objectif de cet article n'est pas de reprendre cet exercice de style, mais d'étudier un cas pratique, et surtout complet, d'automatisation de déploiement d'un serveur.

Depuis l'arrivée des réseaux sociaux [1] à la Facebook [1.1] ou professionnels à la LinkedIn [1.2], la notion de messagerie a clairement beaucoup évolué et les attentes des utilisateurs ont évolué de concert. Ces derniers souhaitent désormais un outil de messagerie plus élaboré et plus convivial que le mail traditionnel, et, surtout, de plus en plus de personnes réclament une amélioration de la messagerie dans le cadre de leur travail. Ainsi, l'utilisation de ces nouveaux systèmes de messagerie a même amené certains grands groupes, comme Atos Origin [1.3], à revoir leur propre infrastructure de mails pour adopter une approche dite plus « 2.0 ».

L'heure du Cloud ayant sonné, il va être temps de revoir nos degrés d'exigence en termes de scripts Bash. En effet, finis les scripts à moitié dysfonctionnels ou cassés, le Cloud ne les permet plus ! Pourquoi ? Parce que le « Cloud » demande de la robustesse, les systèmes qui s'y exécutent doivent survivre aux pannes et autres coupures de réseaux... Oui, mais comment faire ? Comment rendre ses scripts plus robustes et plus propres ? Petite explication de texte dans cet article...

Depuis maintenant plusieurs années, l'informatique « dans les nuages » [1.1] est présentée comme le parfait nouveau « datacenter » : virtuel, simple, économique, puissant et surtout tenant parfaitement la montée en charge. Évidemment, derrière une telle image d'Épinal se cache une réalité quelque peu différente. Cet article, parmi d'autres, prend donc le parti d'étudier, de manière pratique, une problématique volontairement réduite : la mise en place de l'infrastructure nécessaire au déploiement d'applicatifs dans « les nuages ». Ceci pour illustrer que si le « Cloud » est certainement une solution très intéressante en termes d'infrastructure, elle s'accompagne néanmoins et nécessairement d'une adaptation de nos usages et habitudes dans le domaine, mais aussi d'une évolution des outils usuels comme de leur utilisation. Basculer d'une infrastructure physique « classique » à une infrastructure aussi virtuelle ne se fait donc pas de manière aussi transparente que de nombreux slides essayent de nous faire croire...

Parmi les langages émergeant, Scala a clairement le vent en poupe et fait partie, tout du moins dans le monde Java, de ceux qui sont le plus étudiés ces derniers temps. Néanmoins, sa complexité (apparente ou avérée [1.1]) paralyse souvent les développeurs qui souhaiteraient s'y frotter.

En quelques années, Sonar, un projet open source point d'origine de la société SonarSource, est rapidement devenu une référence du marché et certainement le leader de sa catégorie parmi les produits open source. La qualité incontestable du produit, ainsi que sa souplesse, justifient pleinement cette adoption. Cet article vise donc à exposer la facilité d'utilisation et de mise en place de cet outil, en espérant ainsi vous inciter vous aussi à en devenir un utilisateur régulier.

Il y a maintenant presque un an, Google dévoilait la version Java de son environnement de « cloud », la solution Google App Engine. Tout en prenant le cadre « classique » d'une application web Java, ce nouvel environnement de développement offre sa part de nouveautés, mais propose surtout une nouvelle approche à la mise en place d'applications web. Expérimentons, par la réalisation d'une petite application, cette nouvelle approche.

Java et le monde JEE ayant plus de 10 ans aujourd'hui, beaucoup de progrès, en termes d'industrialisation, ont été réalisés depuis ses débuts, et le monde open source y a très largement contribué. Cet article propose donc un tour d'horizon du sujet pour bien comprendre les enjeux de l'industrialisation et le rôle qu'y jouent de nombreuses technologies open source.

Depuis maintenant plus de deux ans, les gestionnaires de sources distribués ont pris une part de plus en plus importante dans le monde des logiciels libres et open source. De plus en plus de ces projets migrent vers Git, Mercurial ou encore Bazaar. Si la plupart des développeurs de ce monde sont convaincus des apports de ces outils dans leur travail, le reste de l'industrie reste pour le moment confiné à des gestionnaires de sources centralisés, comme SVN. Pourtant, il existe avec git-svn le moyen de combiner les deux éléments et de pouvoir bénéficier de presque tous les avantages des gestionnaires distribués, tout en utilisant un serveur SVN. Si les développeurs habitués aux usages des gestionnaires de sources distribués l'adoptent de manière immédiate lorsqu'ils doivent travailler avec un serveur SVN, les développeurs habitués à ce dernier n'ont que rarement ce réflexe. Le propos de cet article est donc de présenter en détail et de manière pratique l'utilisation quotidienne que peut faire un développeur utilisant SVN de git, avec git-svn.