Notre env. de dév. n’est plus unbizutage !

Speaker : Julien
L'installation était vécu comme un bizutage par les nouveaux arrivants
Retour d'expérience de pourquoi plutôt qu'un listing de commande

Photo par Stéfan sur Flickr, CC-BY-NC-SA.

Appuyez sur [s] pour ouvrir les notes présentateur dans une nouvelle fenêtre.

Je vais essayer d'ajouter ici, pour certains slides, des points que j’ai pu donner à l’oral lors de la présentation et/ou qui ne sont pas explicitement écrits sur les slides — afin de les rendre plus utiles aux lecteurs qui n’auraient pas assisté à la présentation.

Le style sera volontairement un peu oral, se rapprochant un peu de ce qui s’est dit lors de la présentation live.

Qui sommes-nous ?

Julien FUSCO

http://koin.github.io @PKoin

#MarioKart8 #montagne #pasDeFootPitié

Photo par Stéfan sur Flickr, CC-BY-NC-SA.

Speaker : Julien
Julien, 8 ans d'XP
Gros background SSII
Dév PHP, Ruby principalement
J'aime beaucoup Mario Kart, on s'échange nos ID Nintendo ?

Qui sommes-nous ?

Pascal MARTIN

http://blog.pascal-martin.fr pmartin@php.net @pascal_martin

#éléphpantarque #chatons #14h00

Photo par Stéfan sur Flickr, CC-BY-NC-SA.

Speaker : Pascal
Pascal, 8 ans d'XP, SSII puis éditeur puis startup.
Principalement du PHP, touche un peu à tout aussi.
J'aime les chats \o/

TEA, The Ebook Alternative

Photo par Stéfan sur Flickr, CC-BY-NC-SA.

Speaker : Pascal
Start-up sur le livre numérique
Une quinzaine de personnes
Entreprise fondée il y a 3 ans

Notre équipe

Photo par Stéfan sur Flickr, CC-BY-NC-SA.

Speaker : Pascal
Julien arrivé il y a presque 3 ans, 2ème dev
Pascal arrivé il y a presque 1 an, 4ème dev
Aujourd’hui, 7 développeurs
Un 8ème bientôt
Pas les mêmes compétences : front, back, admin-sys, architecture...
Pas la même xp : de 8 ans à 3 mois
Agile, Scrum

Ce qui est fixé

(pour le moment)

Git, Github
(Portable) Linux, Mac
HipChat <3

Photo par JD Hancock sur Flickr, CC-BY.

Speaker : Julien
Chez TEA, on aime git et github
Github : PRs (c'est systématique) + wiki
Portable pour : le télétravail, le travail en pair
Pas tous les mêmes distribs : Mac OSX, Debian, Ubuntu
Communication (équipe qui grossie, télétravail) : Hipchat

Notre production

Linux, Apache, PHP, Ruby
MySQL, MongoDB, Redis
Silex, Symfony 1.4, Rails 3, Rails 4, Magento, …
Outils propriétaires
Déploiement : capistrano

Photo par Kristina Alexanderson sur Flickr, CC-BY-NC-SA.

Speaker : Julien
Explication de notre production pour expliquer la compléxité de notre archi
Debian sur nos serveurs, 7 serveurs physiques, ~15 VMs entre dev, preprod, prod
Stack LAMP, Ruby et aussi MongoDB, Redis, SolR
Outils proprio : boites noires, pas la main dessus
prestataires qui nous ont livré une production qu'on a du reverse-engineerer

« Bienvenue ! Tu vas prendre en gros la semaine pour installer ton poste. (sic) »

Speaker : Pascal
Un de mes collègues, le jour de mon arrivée

Moué…

Photo par JD Hancock sur Flickr, CC-BY.

Speaker : Pascal
Bon, une semaine, projets compliqués, pourquoi pas
Ça doit compter le temps de commencer à comprendre comment ça marche

« Comme ils ont dû te dire, tu vas en avoir pour à peu près deux semaines à installer ton poste »

Speaker : Pascal
Un autre de mes collègues, quelques heures plus tard

WAT?

Photo par Stéfan sur Flickr, CC-BY-NC-SA.

Speaker : Pascal
C’est beaucoup quand même
Plate-forme hyper-ultra-mega-compliquée ?

Mais pourquoi ? …

+ de 20 projets
~ 13 serveurs
10 technos
Applications très liées

… en moins de 3 ans

Photo par Kristina Alexanderson sur Flickr, CC-BY-NC-SA.

Speaker : Pascal
Start-up nécessite de délivrer vite en prod, visibilité des produits

… À l’image de la prod ?

Architecture
Isolation des services
Droits d’accès (fichiers, ressources)

Kristina Alexanderson sur Flickr, CC-BY-NC-SA.

Speaker : Pascal
Importance de s'assurer que ce qu'on fait va fonctionner en prod

Pas d’automatisation

2012 - 2013

Photo par Stéfan sur Flickr, CC-BY-NC-SA.

Speaker : Julien
Mission de base : Encadrer les presta externe
Que 2 devs pour tout faire
Livraison d'une production, pas de vision globale sur l'archi mise en place

Au départ

Doc peu (pas ?) à jour sur un wiki

Photo par Stéfan sur Flickr, CC-BY-NC-SA.

Speaker : Julien
Lancement de la boite, pour aller vite, code fait par des presta
Un peu "reverse-engineering" de ce qui avait fait pour l’installer sur les postes de dev
Tout manuel, depuis le wiki ; ce qui entraine des erreurs
docs pas toujours à jour => des erreurs
Wiki : notes dans tous les sens (parfois contradictoires d’une fiche à l’autre !), commandes à copier-coller, pas mis à jour aussi régulièrement qu’il ne faudrait, fichiers de conf à créer à la main, instructions du genre "remplacer X par Y", pas automatisé / automatisable

VirtualBox

Installation manuelle

Photo par Stéfan sur Flickr, CC-BY-NC-SA.

Speaker : Pascal
VirtualBox pour environnement proche de la prod
Vagrant : faciliter lancement / arrêt des VM
Installation manuelle dans les VM !
Tout à refaire à la main à chaque nouvelle installation
Pas d’utilisation du provisionning de Vagrant

Collègue, pendant une semaine, a pris son PC (fixe) et est venue en pair avec moi

Photo par JD Hancock sur Flickr, CC-BY.

Speaker : Pascal
Pas mal de perte d’efficacité
Côté positif : transmission (explication, réponse instantanée aux questions)
BEAUCOUP de mise à jour de documentations, en notant tout ce qui avait foiré lors de mon install
Au final : poste + ou - installé ; un peu le bordel vu qu’il avait fallu tester plusieurs trucs, des fois, pour que ça marche

Automatisation

Depuis 2014

Photo par Stéfan sur Flickr, CC-BY-NC-SA.

Speaker : Julien
Début 2014, recrutement intensif, beaucoup de nouveaux
"C'était le moment d'améliorer cette partie"

Quelques outils

Vagrant provision
Cookbooks Chef

Kristina Alexanderson sur Flickr, CC-BY-NC-SA.

Speaker : Julien
On a aussi fait ça parce qu’on a tous changé de machines (portables), et donc tous on a du réinstaller
Re-jouable à volonté
Cookbooks jouent aussi un rôle de doc ! Vu que pour installer quelque chose, on modifie les cookbooks et on fait une PR (vue par l’équipe, donc)

Cookbook chef

include_recipe "php"
include_recipe "php::module_mysql"

package "php5-xdebug" do
  action :install
end

service "apache2" do
  action [ :restart ]
end

Speaker : Julien
c'est du ruby même si vous n'en avez jamais fait ça reste très facile
include_recipe : utilisation d'une recette écrite par la communauté
installation de php, du module mysql pour php, xdebug et restart apache

Vagrantfile

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|

  config.vm.define "tea-phptour" do |test|
    test.vm.box = "tea-wheezy-amd64"
    test.vm.hostname = "tea-phptour"

    test.omnibus.chef_version = :latest

    test.vm.provision "chef_solo" do |chef|
      chef.cookbooks_path = "#{my_ws}/cookbooks"
      chef.add_recipe "tea-phptour"
    end
  end

end

Speaker : Julien
utilisation d'une base box perso juste pour : vim, htop, tree, tmux...
installation de chef solo via le plugin omnibus

vagrant up tea-phptour

Speaker : Julien
lors du premier up, les cookbooks sont joués et les packages s'installent tout seul

Pour les données ? Scripts !

(bash) Import depuis la prod
(SQL) Nettoyage des données sensibles

Photo par Kristina Alexanderson sur Flickr, CC-BY-NC-SA.

Speaker : Julien
Backups réguliers en prod
Adapter = supprimer données confidentielles, anonymiser, …
Solr : reconstruction des indexes depuis la DB

Malgré cela…

Cloner le repo git
Créer la VM
composer install
Les tests passent…
… ou pas !

Photo par JD Hancock sur Flickr, CC-BY.

Speaker : Pascal

Configuration

Très chronophage

Avant : fichiers .dist
Maintenant : stow

Photo par Stéfan sur Flickr, CC-BY-NC-SA.

Speaker : Pascal
Application métier complexe avec nombreux (+ de 10) fichiers de configuration, réparti dans plusieurs sous-répertoires
TRES consommateur en temps et énergie à configurer

Stow

Arborescence extraite de git

$ tree
.
|-- app
|   `-- config
|-- config
`-- config-dist
    `-- local
        |-- app
        |   `-- config
        |       `-- specifique-appli.txt
        `-- config
            `-- test.yml

Speaker : Pascal
Possible uniquement parce que les environnements sont très proches chez tout le monde (hôtes des VM / services, notamment)
Exemple "avant" de lancer la commande stow

Stow

$ stow --dir=config-dist --target=. local

Speaker : Pascal

Stow

Arborescence avec les symlinks

$ tree
.
|-- app
|   `-- config
|       `-- specifique-appli.txt
            -> ../../config-dist/local/app/config/specifique-appli.txt
|-- config
|   `-- test.yml -> ../config-dist/local/config/test.yml
`-- config-dist
    `-- local
        |-- app
        |   `-- config
        |       `-- specifique-appli.txt
        `-- config
            `-- test.yml

Speaker : Pascal
Même chose "après" lancement de la commande stow
Si quelqu’un modifie un fichier de config, la modification passe dans la PR de la feature sur laquelle il bossait, et tous les collègues en profitent
Si un poste des "trop différent" des autres, ça va poser problème ; pour l’instant, on voit sur un projet si "ça marche" (ça a l’air pas trop mal parti) ; ensuite on va faire pareil sur 1 ou 2 autres ; puis les suivants

dnsmasq

Serveur DNS utilisé par toutes les machines

Photo par Stéfan sur Flickr, CC-BY-NC-SA.

Speaker : Pascal
Problématique : comment faire pour que les services se parlent entre eux ?
IP en dur : pas viable
Modifier les fichiers /etc/hosts partout : fastidieux, manuel, à faire dans chaque VM, pas possible sous Docker (peut-être que si, maintenant ? )
Serveur DNS sur poste de dev : 1 seul endroit où effectuer les configurations

Sur le poste de dev.

# /etc/dnsmasq.conf
bind-interfaces
conf-dir=/etc/dnsmasq.d

# /etc/dnsmasq.d/ecommerce.local
address=/ecommerce.local/192.168.3.13

# /etc/dnsmasq.d/database.local
address=/database.local/192.168.3.10

sudo /etc/init.d/dnsmasq restart

Speaker : Pascal
Sur le poste physique, on installe dnsmasq et on le configure pour qu'il chager tous les fichiers depuis dnsmasq.d
Ensuite, un fichier par service (plus facile pour semi-automatiser leur création) avec nom du service + IP

Sur les VMs

apt-get install resolvconf

# /etc/resolvconf/resolv.conf.d/head
nameserver 192.168.3.1

Speaker : Pascal
Sur chaque VM, IP du poste physique (sur l'interface de virtualisation), qui est utilisé pour la résolution DNS
On n'a plus 36 lignes dans /etc/hosts, mais une seule pour la résolution, qui ne change globalement jamais

Objectif atteint !

Photo par JD Hancock sur Flickr, CC-BY.

Speaker : Julien
installation automatique des packages et des dépendances
plus de longue étape : "créer tous les fichiers de conf avec les bonnes valeurs"

Objectif atteint !

                        
$ git clone mon-projet.git
$ vagrant up ma-vm
$ composer install
$ stow --dir=config-dist local

$ bin/atoum && bin/behat

\o/

Speaker : Julien

Boîte à outils

Initialisation de l’env de dev
Connexion serveurs dev, preprod, prod
Déploiement clefs SSH

Photo par Stéfan sur Flickr, CC-BY-NC-SA.

Speaker : Julien
Github, Heroku toolbelt
Commande pour simplifier, abstraire ce qu'on a vu précédemment

tea-sub

#!/usr/bin/env bash
# Summary: (tea) development server
# Usage: tea dev [actions] [user]
# Help:
#   Possible actions:
#   warehouse   Users: tea (default), warehouse
#   db          Users: tea (default)
#   acs         Users: tea (default), acs
set -e

DIRNAME=`dirname $0`

connect() {
  set_color FFFFFF 7A4B0C
  ssh "$1"@tea-"$2"-pp.teaebook
  set_color FFFFFF 000000
}

# ...

Speaker : Julien
Sub : développé par l'équipe de Basecamp
mutualisation de commandes communes aux devs
autocomplétion des sous-commandes

tea-sub

Connexion à la pre-prod

$ tea preprod db

Speaker : Julien

tea-sub

Connexion à la prod

$ tea prod db

Speaker : Julien

Chacun son poste de dev

Linux, Mac
IDE, Sublime Text, vim
VirtualBox, Docker

Photo par Stéfan sur Flickr, CC-BY-NC-SA.

Speaker : Julien
Laisse quand même pas mal de liberté à chacun
Autrement dit : avantages de l’automatisation, sans pour autant que ça ne soit une contrainte

En plus !

Facilite la montée de versions
Mise en place d’une PIC

Photo par Stéfan sur Flickr, CC-BY-NC-SA.

Speaker : Pascal
Utile pour migration versions PHP, Varnish, Apache -> nginx, Ruby
Cookbooks à mettre à jour par 1 personne, et tout le monde en profite
Facile de basculer d’une version à l’autre (suffit de rebuilder la VM, au pire)

WIP constant

Correction
Amélioration
Création

Kristina Alexanderson sur Flickr, CC-BY-NC-SA.

Speaker : Pascal
Stow : en place sur quelques projets, à poursuivre "au fil de l’eau"
Cookbooks : encore quelques projets (ceux sur lesquels on ne bosse en gros jamais) à faire

Expérimenter !

Docker
PHP 5.6
Ruby 2.1
Apache → Nginx

Photo par Stéfan sur Flickr, CC-BY-NC-SA.

Speaker : Pascal
"Sensation d'envoyer une fusée dans l'espace"

Pas toujours parfait

L’important, c’est d’avancer

Photo par Jim Bauer sur Flickr, CC-.

Speaker : Pascal
Bien sûr, expérimenter ne mène pas toujours à une solution parfaite
Et encore moins du 1er coup
Mais c’est comme ça qu’on avance, par petits incréments

Notre env. de dév. n’est (presque)plus un bizutage :-)

Kristina Alexanderson sur Flickr, CC-BY-NC-SA.

Speaker : Julien
Récapitulatif
chef pour le provisionnement des boxes sous virtualbox et vagrant
stow pour la config
composer ou bundler pour les dépendances
script shell pour les données
piloté par une toolbelt qui va bien

Questions ?

http://koin.github.io @PKoin

http://blog.pascal-martin.fr @pascal_martin

Photo par JD Hancock sur Flickr, CC-BY.

Speaker : Julien

Apéro

Photo par Stéfan sur Flickr, CC-BY-NC-SA.

On sera tous deux présents à l’apéro communautaire ce soir
(vu qu’on fait la dernière conf de la journée, profitons-en)

Notre env. de dév. n’est plus unbizutage !

Koin

Notre env. de dév. n’est plus unbizutage !

0 0 (function() { var po = document.createElement('script'); po.type = 'text/javascript'; po.async = true; po.src = 'https://apis.google.com/js/platform.js'; var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(po, s); })();

notre-env-de-dev-n-est-plus-un-bizutage

Notre env. de dév. n’est plus unbizutage !

Qui sommes-nous ?

Julien FUSCO

Qui sommes-nous ?

Pascal MARTIN

TEA, The Ebook Alternative

Notre équipe

Ce qui est fixé

Notre production

Mais pourquoi ? …

… À l’image de la prod ?

Pas d’automatisation

2012 - 2013

Au départ

VirtualBox

Automatisation

Depuis 2014

Quelques outils

Cookbook chef

Vagrantfile

vagrant up tea-phptour

Pour les données ? Scripts !

Malgré cela…

Configuration

Très chronophage

Stow

Stow

Stow

dnsmasq

Sur le poste de dev.

Sur les VMs

Objectif atteint !

Objectif atteint !

Boîte à outils

tea-sub

tea-sub

tea-sub

Chacun son poste de dev

En plus !

WIP constant

Expérimenter !

Pas toujours parfait

L’important, c’est d’avancer

Questions ?

Apéro

0 0