Artisan Développeur

Qualité, amélioration continue, agilité.

Results for category "Blog"

49 Articles

Pac manager pour gérer les connexions ssh

J’ai plusieurs serveurs auxquels je dois accéder pour faire des mises à jour, et autres interventions, via ssh.

En cherchant un gestionnaire, j’ai rapidement trouvé pac manager, que je vais essayer.

L’install :

(dans mon cas kubuntu 15.04)

1 – télécharger le .deb http://sourceforge.net/projects/pacmanager/
2 – les dépendances :

[pastacode lang= »bash » message= » » highlight= » » provider= »manual »]

sudo apt-get install libgnome2-gconf-perl libexpect-perl libnet-proxy-perl libyaml-perl libcrypt-cbc-perl libcrypt-blowfish-perl libgtk2-gladexml-perl libnet-arp-perl libossp-uuid-perl libcrypt-rijndael-perl libio-stty-perl libossp-uuid16 libgtk2-unique-perl libunique-1.0-0 libgtk2-appindicator-perl

[/pastacode]

3 – install de pac :

[pastacode lang= »bash » message= » » highlight= » » provider= »manual »]

sudo dpkg -i pac-XX-Version.deb

[/pastacode]

4 – ???

5 – profit (Il n’y a plus qu’à tester !)

 

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.

[pastacode lang= »bash » message= » » highlight= » » provider= »manual »]

$ 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]

[/pastacode]

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 !