Artisan Développeur

Qualité, amélioration continue, agilité, professionnalisme.

Ajouter un environnement de preproduction à symfony2

Un petit How -to, simple, pour ajouter un environnement à symfony2.

(le cookbook symfony2 sur les environnements)

Par défaut, il y a 3 environnements avec symfony2 :

  • dev
  • prod
  • test

L’environnement de prod (production) est celui chargé lorsqu’on utilise l’url du projet (http:localhost/monProjetSf2/) qui pointe sur web/app.php

Selon la configuration du Vhost, sinon c’est http:localhost/monProjetSf2/web/ si votre vhost pointe sur la racine de votre symfony2.

L’environnement « test » n’a pas de fichier dédié dans web/ il n’est utilisé que pendant les tests fonctionnels, il n’a pas de contrôleur frontal.

Maintenant le contexte:

Je travail en local, c’est l’environnement dev, j’ai une préproduction et un production sur le serveur distant.

Je n’ai pas les mêmes accès base de données, je n’ai pas les même besoins de logging. Composer crée un app/config/parameters.yml avec les configuration de la base de donnée, et le mailer (entre autre) commun à tous les environnements.

J’ajoute donc un environnement preprod, qui va embarquer entre autre la configuration de la base de donnée.

1) app/config/parameters.yml

Je commence par commenter les lignes en rapport avec la BDD , je laisse juste database_driver celui dans mon cas étant identique entre mon local et le distant.

# This file is auto-generated during the composer install
parameters:
    database_driver: pdo_mysql
    #database_host: 127.0.0.1
    #database_port: null
    #database_name: nameOfDatabase
    #database_user: root
    #database_password: MonMotDePasseLocalQuiNestPasBeauAVoir
    mailer_transport: smtp
    mailer_host: 127.0.0.1
    mailer_user: null
    mailer_password: null
    locale: fr
    secret: 'bépoèdljzw'

 

2) fichier de configuration config_preprod.yml

J’ai choisis d’avoir le webProfiler, d’où l’import des routes, les logs « debug » et les warning par mail.

#app/config/config_preprod.yml
imports:
    - { resource: config_prod.yml }

framework:
    router:
        resource: "%kernel.root_dir%/config/routing_preprod.yml"
        strict_requirements: true
    profiler: { only_exceptions: false }

monolog:
    handlers:
        main:
            type:   stream
            path:   "%kernel.logs_dir%/%kernel.environment%.log"
            level:  debug
        swift:
            type:               swift_mailer
            from_email:         monEmailAMoi@bienFaitPourLesRobotsSpammer.com
            to_email:           monEmailAMoi@.com
            subject:            "[LogPreprod]"
            level:              warning

# Doctrine Configuration
doctrine:
    dbal:
        host:     "localhost"
        port:     null
        dbname:   "distantDbName"
        user:     "distantBdUsenName"
        password: "distantUserPassword"
        charset:  UTF8


3) app/config/routing_preprod.yml

J’ai besoin des routes pour le profiler.

_wdt:
    resource: "@WebProfilerBundle/Resources/config/routing/wdt.xml"
    prefix:   /_wdt

_profiler:
    resource: "@WebProfilerBundle/Resources/config/routing/profiler.xml"
    prefix:   /_profiler

_configurator:
    resource: "@SensioDistributionBundle/Resources/config/routing/webconfigurator.xml"
    prefix:   /_configurator

_main:
    resource: routing.yml

4) ne pas oublier config_prod.yml et config_dev.yml

Eux aussi ont besoin d’avoir les configuration de base de données.

# Doctrine Configuration
doctrine:
    dbal:
        host:     "localhost"
        port:     null
        dbname:   "DbName local ou distant prod"
        user:     "BdUserName local ou distant prod"
        password: "UserPassword local ou distant prod"
        charset:  UTF8

5) Le contrôleur frontal pour la preprod web/app_preprod.php

Je me base sur le contrôler de dev, pour avoir le debug :
La sécurité par ip est pas mal, mais si vous ou les testeurs de votre préprod n’ont pas d’ip fixe, vous pouvez commenter et installer simplement un htaccess/htpasswd.

On change simplement le nom de l’environnement.

<?php

use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\Debug\Debug;

// This check prevents access to debug front controllers that are deployed by accident to production servers.
// Feel free to remove this, extend it, or make something more sophisticated.


if (isset($_SERVER['HTTP_CLIENT_IP'])
    || isset($_SERVER['HTTP_X_FORWARDED_FOR'])
    || !(in_array(@$_SERVER['REMOTE_ADDR'], array('127.0.0.1', 'fe80::1', '::1')) || php_sapi_name() === 'cli-server')
) {
    header('HTTP/1.0 403 Forbidden');
    exit('You are not allowed to access this file. Check '.basename(__FILE__).' for more information.');
}

$loader = require_once __DIR__.'/../app/bootstrap.php.cache';
Debug::enable();

require_once __DIR__.'/../app/AppKernel.php';

$kernel = new AppKernel('preprod', true);
$kernel->loadClassCache();
$request = Request::createFromGlobals();
$response = $kernel->handle($request);
$response->send();
$kernel->terminate($request, $response);

6) modification app/AppKernel.php

Je veux avoir le profiler, qui n’est chargé que pour le dev, j’ajoute donc une condition pour charger ce dont j’ai besoin pour le debug lors de l’utilisation de l’env de preprod, directement en dessous du bloc conditionnel pour dev et test :

if (in_array($this->getEnvironment(), array('preprod'))) {
    $bundles[] = new Symfony\Bundle\WebProfilerBundle\WebProfilerBundle();
    $bundles[] = new Sensio\Bundle\DistributionBundle\SensioDistributionBundle();
}

Finis ! A présent, j’ai mon environnement de préproduction, avec les configurations distantes de base de données, le logging fichier + mail spécifique, avec le reste de la configuration le plus proche possible de la prod, comme les assets, twig, les firewall etc.

Tester une Pull Request sur le repo de quelqu’un d’autre

Ce matin c’est tout bête, j’ai prévu de tester cette PR https://github.com/andres-montanez/Magallanes/pull/184

Jusqu’à maintenant je n’ai jamais eu besoin de tester la PR d’un contributeur, sur le repo d’une autre personne, voilà le contexte :
Il y a le repo de base, avec une branche develop.
Pour proposer une modification du code, il faut forker la branche develop et faire une PR avec les modifications.
Jusque là, c’est habituel.

Une PR est en cours sur un fonction dont j’ai besoin, pour ajouter une variable d’environnement SYMFONY à la commande Composer.

Comment faire pour tester ?

La solution que j’ai utilisée (libre à vous de proposer autre chose si vous avez), j’utilise phpStorm pour coder, avec le plugin d’intégration Github.

Créer une nouvelle branche from upstream/develop
remoteUpstream

Ensuite, récupérer le patch de la PR depuis Github, pour faire ça, je préfère wget, donc en Konsole (gnome-terminal, peu importe lequel), je vais dans le rép où je stocke mon projet. Merci à igthub, il suffit d’ajouter .patch à la fin de l’url pour avoir le fichier patch.

$ wget https://github.com/andres-montanez/Magallanes/pull/184.patch

--2015-02-04 14:58:50-- https://github.com/andres-montanez/Magallanes/pull/184.patch
Résolution de github.com (github.com)... 192.30.252.130
Connexion vers github.com (github.com)|192.30.252.130|:443... connecté.
requête HTTP transmise, en attente de la réponse... 200 OK
Taille : non spécifié [text/plain]
Enregistre : «184.patch»

[ <=> ] 5 141 24,3KB/s ds 0,2s

2015-02-04 14:58:51 (24,3 KB/s) - «184.patch» enregistré [5141]

Ensuite, et merci à phpStorm, il suffit de faire :

Menu -> VCS -> Apply patch

applyPatch

Dans la liste de choisir le patch récupéré

applyPatch1

Puis de valider les modifications
applyPatch2

Une dernière fenêtre montre les modifications effectuées.

Maintenant j’ai une branche locale, à jour sur la branche de dev du repo d’origine, avec le code de la PR à tester appliqué.

Il n’y a plus qu’à tester !

Test install beta de blackfire.io

Aujourd’hui je commence le dev d’un nouveau projet, avec Symfony2, dans l’optique de l’amélioration continue (KaiZen), je me suis penché un peu sur les profiler, et puisque Sensio Lab lance un nouveau produit on va tester 🙂
Pour les tests je fais tout en local, Kubuntu 14.10.

$ apache2 -v
Server version: Apache/2.4.7 (Ubuntu)
Server built: Jul 22 2014 14:36:38

$ php -v
PHP 5.5.9-1ubuntu4.5 (cli) (built: Oct 29 2014 11:59:10)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies
with Zend OPcache v7.0.3, Copyright (c) 1999-2014, by Zend Technologies
with Xdebug v2.2.3, Copyright (c) 2002-2013, by Derick Rethans

Avant tout s’enregistrer sur le site, avec le compte github ou sensio c’est rapide.
S’enregistrer sur blackfire.

L’installation est vraiment simple, https://blackfire.io/getting-started
, sous ubuntu, j’ai utilisé le repo pour debian et tout s’est bien passé.
(petite astuce pour éviter les sudo tout le long, alt+F2 puis kdesudo konsole – pour kde – ou gksudo gnome-terminal)

Vous aurez besoin des id et token pendant la config, disponibles à cette adresse, en étant identifié :
https://blackfire.io/account/credentials

Les commandes condensées:

curl -s https://packagecloud.io/gpg.key | sudo apt-key add -

echo "deb http://packages.blackfire.io/debian any main" | sudo tee /etc/apt/sources.list.d/blackfire.list

sudo apt-get update

sudo apt-get install blackfire-agent

sudo blackfire-agent -register #credentials serveur

sudo /etc/init.d/blackfire-agent restart

blackfire config #credentials client

sudo apt-get install blackfire-php

sudo apache2ctl restart

Pour utiliser le plugin web, il faut utiliser chrome pour l’instant (vivement le plugin firefox), il faut aller sur cette page, et installer le plugin :

https://blackfire.io/doc/web-page

Une fois installé, on clique dessus, on choisit le slot, qu’il est préférable de renommer, puis « Profile! ».

companion

2

Et enfin les données du profiler :
3

Il ne reste plus qu’à bien étudier les infos remontées, au fur et a mesure de l’avancement du code.