Déployez votre application PHP avec Rocketeer

Il était un temps où les développeurs PHP devaient utiliser des outils de déploiement destinés aux applications Web générales. Vous pouvez le voir dans le tutoriel de Johannes Schickling sur le déploiement d'applications Laravel avec Capistrano, par exemple. C'est un outil Ruby, et vous devez écrire du code Ruby. Ces outils font le travail mais ont une intégration limitée avec les applications PHP. Cela peut conduire à des solutions optimales pour certains scénarios. 

Mais de nos jours, nous avons la chance de disposer de quelques outils de déploiement écrits dans notre langue qui permettent une intégration plus profonde. Rocketeer est l’un de ces outils qui s’inspire de Capistrano et du framework Laravel..

Rocketeer est un outil moderne qui apporte une excellente approche pour vos besoins de déploiement. Cela consiste à exécuter des tâches et à gérer votre application dans différents environnements et serveurs. En plus de cela, il a aussi une certaine magie, comme installer des dépendances Composer s'il détecte une composer.json fichier. Vous obtenez des valeurs par défaut saines et l'automatisation des tâches courantes d'une application PHP moderne. Et vous avez la possibilité de personnaliser et d'étendre tout.

Vous pouvez le décrire comme un exécuteur de tâches SSH qui s'exécute côté client. Les commandes s'exécutent sur des serveurs via une connexion SSH. Si vous utilisez un fournisseur d'hébergement partagé avec uniquement un accès FTP, vous ne pourrez malheureusement pas la chance. Vous avez également besoin d'un référentiel distant où l'outil peut récupérer votre code. Git et SVN sont pris en charge par défaut. Besoin d'assistance pour un autre système de contrôle de version? Écrivez votre propre implémentation avec les interfaces fournies.

Installation

Vous pouvez installer Rocketeer de deux manières différentes. Soit vous téléchargez le fichier phar et le rendez exécutable, soit vous l'installez via Composer. Je suis un partisan de ce dernier. Avoir cela comme dépendance permet une installation facile lors du clonage du référentiel. Cela peut profiter à quiconque clonant le référentiel pour le rendre opérationnel.

Installation avec Composer:

$ composer exige anahkiasen / rocketeer --dev

Je ne vous recommande pas de l'installer globalement. Le garder au niveau du référentiel garantira que chaque personne déployant exécute la même version. Ce que je recommande est que vous ajoutiez fournisseur / bin à votre chemin. Ensuite, vous pouvez utiliser le binaire en tapant fusée dans la racine de votre projet.

Allumage

Commençons! Commencez par amorcer les répertoires et les fichiers pour la configuration. Vous faites cela en exécutant rocketeer s'enflammer à la racine de votre projet.

Lorsque votre application s’allume, l’outil crée une .fusée dossier dans votre projet. Le contenu du répertoire ressemblera à ceci:

| .rocketeer | - config.php | - hooks.php | - paths.php | - remote.php | - scm.php | - stages.php | - strategies.php

Ce sont tous les fichiers de configuration dont vous avez besoin pour commencer à configurer vos déploiements. Chaque fois que je me réfère à un fichier de configuration à partir de maintenant, il existe dans le .rocketeer / annuaire.

Structure des dossiers distants

Il est important de comprendre comment Rocketeer gère la structure de ses dossiers côté serveur, car elle diffère légèrement de celle d’une installation normale. Il utilise quelques répertoires pour gérer certains aspects du déploiement, ce qui lui permet de fonctionner efficacement. Vous spécifiez un chemin d'accès à l'endroit où vous souhaitez déployer votre application sur votre serveur, et l'outil se chargera du reste. Ce dossier va ressembler à ceci, si vous avez / var / www / app comme votre répertoire d'application.

| / var / www / app | | - current => / var / www / app / releases / 20160103183754 | | - communiqués | | | - 20160101161243 | | | | - uploads => / var / www / app / shared / uploads | | | - 20160103183754 | | | | - uploads => / var / www / app / shared / uploads | | - partagé | | | - uploads

Le dossier le plus important est actuel, qui pointe vers votre dernière version. C’est là que la racine du document de votre serveur Web doit être définie. Alors, que se passe-t-il lorsque vous déployez?

  1. L'outil crée un dossier horodaté dans le dossier les libérations annuaire.
  2. Termine toutes les tâches pour créer une version prête.
  3. Met à jour le lien symbolique actuel à la nouvelle version.

Ce processus rend votre déploiement transparent pour l'utilisateur. Le basculement entre les versions est presque instantané, généralement appelé déploiements atomiques.

Certaines données doivent être persistantes entre vos déploiements. Cela peut être par exemple des téléchargements de fichiers, des sessions utilisateur et des journaux. Ces fichiers ou dossiers vont dans le partagé annuaire. L'outil crée des liens symboliques dans chaque version pour ceux que vous avez configurés..

Événements

Les événements pilotent l’outil, et toutes les stratégies et tâches déclenchent avant et après événement quand ils courent. Ils fournissent également une spéciale arrêt événement quand une tâche échoue. Cela pourrait être par exemple dépendances.halt, ou deploy.halt pour l'échec général. Cela nous permet d’accrocher au processus où nous devons.

Les événements par défaut qui se produisent pendant un déploiement sont les suivants:

  • déployer avant: avant que rien ne se passe.
  • create-release.before: avant de créer un nouveau répertoire de publication.
  • create-release.after: après avoir créé un nouveau répertoire de publication.
  • dépendances avant: avant d'installer ou de mettre à jour des dépendances.
  • dépendances.après: après l'installation ou la mise à jour des dépendances. Assurez-vous peut-être que les fichiers binaires de votre dossier de fournisseurs sont exécutables..
  • tester avant: avant de lancer des tests.
  • test.après: après des tests en cours.
  • migrate.before: avant d'exécuter les migrations de bases de données. Peut-être que vous voulez faire une sauvegarde de votre base de données?
  • migrer.après: après avoir exécuté les migrations de bases de données.
  • deploy.before-symlink: avant de créer un lien symbolique avec notre version actuelle.
  • déployer.après: terminé. Vous pouvez informer les gens que tout se passe bien ou autrement.

Nous pouvons également créer nos propres événements que nous pouvons déclencher et écouter. Pour le moment, nous allons nous en tenir à ces événements prévus pour nous. Ils seront assez pour nous maintenant.

les tâches

Au cœur de Rocketeer, nous trouvons un concept appelé les tâches. La plupart de ce qui se passe sous le capot sont des tâches essentielles. La définition d'une tâche peut être un ensemble d'instructions à exécuter en tant qu'étape d'un déploiement. Si nous examinons certaines des classes fournies par l'outil, nous pouvons avoir une idée générale de la nature des tâches: classes telles que DéployerInstallerÉmigrerRetour en arrière, et Les dépendances. Lorsque vous déployez, la commande deploy elle-même est une tâche avec des sous-tâches.

Types de tâches

C’est là que vous commencerez à voir à quel point l’outil est intégré à PHP puisque vous écrirez des tâches dans le langage. Vous pouvez créer vos propres tâches de trois manières différentes:

Commandes de terminal arbitraires. Ce sont des liaisons uniques que vous souhaitez exécuter sur votre serveur. Peut être utile pour beaucoup de choses, comme courir gulp build --- production par exemple.

Fermetures. Si vous avez besoin d'un peu plus de souplesse ou de complexité, vous pouvez écrire une tâche sous forme de fermeture (fonction anonyme). Supposons que vous souhaitiez générer de la documentation pour une API lors de votre déploiement..

function ($ task) return $ task-> runForCurrentRelease ('apigen génère la source src destination api'); 

Des classes. Pour les tâches plus complexes, vous devez utiliser l'option pour créer des classes pour les tâches. Vous créez une classe et étendez Rocketeer \ Abstracts \ AbstractTask. Ensuite, vous devez fournir au moins une description et un exécuter() méthode. Voici un exemple complètement inutile pour montrer la structure d'une classe de tâches:

espace de noms MyDeployableApp \ Deploy \ Tasks; La classe HelloWorld s \ 'étend \ Rocketeer \ Abstracts \ AbstractTask / ** * Description de la tâche * * Chaîne @var * / protected $ description =' Dit bonjour au monde '; / ** * Exécute la tâche * * @retour void * / fonction publique execute () $ this-> expliciter-> line ('Hello world!'); retourne vrai;  

Notez que vous devez inscrire vous-même des classes de tâches. Soit vous faites cela à travers le hooks.php fichier et l'ajouter à la Douane tableau…

'custom' => array ('MyDeployableApp \ Deploy \ Tasks \ HelloWorld',),

… Ou vous pouvez le faire par la façade:

Rocketeer :: add ('MyDeployableApp \ Deploy \ Tasks \ HelloWorld');

Une fois que vous l'avez enregistré, vous pouvez l'exécuter:

$ rocketeer hello: mise en scène mondiale / 0 | HelloWorld (dit bonjour au monde) mise en scène / 0 | => Bonjour tout le monde! Temps d'exécution: 0.004s

Définir les tâches

Nous avons d'abord parlé des événements, car nous associons des tâches là où nous en avons besoin dans le processus. Vous pouvez le faire de plusieurs manières. Choisissez celui que vous aimez et qui répond aux exigences de votre niveau de complexité.

Le moyen le plus simple de définir vos tâches consiste à hooks.php fichier. Il fournit deux tableaux pour cela, spécifiant l'exécution de la tâche avant ou après certains événements..

'before' => ['setup' => [], 'deploy' => ['hello: world'], 'cleanup' => [],],

Stratégies

Vous pourrez peut-être déjà dire que les tâches fournies sont assez génériques. Prendre Les dépendances, par exemple. De quel type de dépendances parle-t-on et quel gestionnaire de paquets? 

C'est ici que stratégies entrer en jeu. Une stratégie est une implémentation spécifique d'une tâche, telle que l'exécution de tests avec Behat ou en utilisant Gorgée pour construire votre front-end. Les tâches ont une stratégie par défaut avec la possibilité d'exécuter les autres stratégies via l'interface de ligne de commande. Nous pouvons lister les stratégies disponibles comme ceci:

stratégies $ rocketeer + -------------- + ---------------- + -------------- -------------------------------------------------- ------- + | Stratégie | Mise en œuvre | Description | + -------------- + ---------------- + ----------------- -------------------------------------------------- ---- + | chèque | Php | Vérifie si le serveur est prêt à recevoir une application PHP | | chèque | Rubis | Vérifie si le serveur est prêt à recevoir une application Ruby | | chèque | Noeud | Vérifie si le serveur est prêt à recevoir une application Node | | déployer | Clone | Clone une nouvelle instance du référentiel par SCM | | déployer | Copie | Copie l'instance précédemment clonée du référentiel et la met à jour | | déployer | Sync | Utilise rsync pour créer ou mettre à jour une version à partir des fichiers locaux | | test | Phpunit | Lancer les tests avec PHPUnit | | migrer | Artisan | Migre votre base de données avec Laravel's Artisan CLI | | dépendances | Compositeur | Installe des dépendances avec Composer | | dépendances | Bundler | Installe des dépendances avec Bundler | | dépendances | Npm | Installe les dépendances avec NPM | | dépendances | Bower | Installe des dépendances avec Bower | | dépendances | Polyglotte | Exécute tous les gestionnaires de paquets ci-dessus si nécessaire | +--------------+----------------+-----------------------------------------------------------------------+ 

Créer vos propres stratégies

Supposons que vous utilisez BDD avec Behat pour votre application au lieu de TDD. Ensuite, vous voulez exécuter vos tests avec Behat au lieu de PHPUnit. Puisque c'est un tester coureur, il existe déjà un espace de noms de stratégie pour cela, mais aucune implémentation. Créer le répertoire .rocketeer / stratégies / et placez votre nouveau BehatStrategy.php là dedans.

espace de noms MyDeployableApp \ Deploy \ Strategies; utilisez Rocketeer \ Abstracts \ Strategies \ AbstractStrategy; utilisez Rocketeer \ Interfaces \ Strategies \ TestStrategyInterface; La classe BehatStrategy étend AbstractStrategy implémente TestStrategyInterface fonction publique test () return $ this-> binary ('vendor / bin / behat') -> runForCurrentRelease (); 

Vous pouvez maintenant passer votre stratégie de test à la nouvelle implémentation dans strategies.php.

'test' => 'Behat',

Connexions et étapes

Peu importe si vous avez une infrastructure en place ou si vous en avez une. Peu importe si votre application se déploie dans de nombreux environnements sur plusieurs serveurs. Rocketeer sera là pour vous. Vous pouvez même avoir plusieurs emplacements différents sur le même serveur. C'est ici que les termes les liaisons et étapes entrer.

UNE lien est un serveur sur lequel vous déployez votre application. Ceci est souvent appelé un environnement, et la production et la mise en scène en sont des exemples. La configuration de ces connexions est un jeu d'enfant dans l'outil. Soit vous le faites via un tableau imbriqué ou en conservant des fichiers séparés pour chaque connexion. Chaque connexion peut également contenir plusieurs serveurs..

Les étapes sont comme des connexions à l'intérieur de connexions, une sorte de "connexionception". Vous pouvez configurer un environnement de transfert et de production sur un serveur unique à l'aide d'étapes. Donc, au lieu d'avoir deux connexions distinctes, vous avez une connexion avec deux étapes en elle.

Plugins

Une fonctionnalité intéressante est que nous pouvons étendre notre processus en utilisant des plugins. Il existe quelques versions officielles pour l'intégration avec Laravel, Slack, HipChat et Campfire. Ensuite, il y en a peu, mais pas beaucoup, sur Packagist. L'installation de plugins est une tâche facile à travers la CLI:

$ plug-in rocketeer: installez rocketeers / rocketeer-slack

Même s'il existe un nombre limité de plugins, cela laisse de la place pour développer des plugins à l'avenir. Cela parle d'une bonne philosophie. Et pourquoi ne pas développer un de vos propres?

Configuration de votre déploiement

Pour lancer votre application, vous avez besoin d’une configuration de base. Vous devez indiquer à Rocketeer où trouver votre application et où elle doit la déployer. Commençons par définir un nom d’application et configurer un serveur de production en config.php.

'application_name' => 'mon-deployable-app', // […] 'connexions' => ['staging' => ['hôte' => 'staging.my-deployable-app.com', 'nom d'utilisateur' => ", 'password' =>", 'key' => '/Users/niklas/.ssh/id_rsa', 'keyphrase' => ", 'agent' =>", 'db_role' => true,] , 'production' => ['hôte' => 'www.my-deployable-app.com', 'nom d'utilisateur' => ", 'mot de passe' =>", 'clé' => '/ Utilisateurs / niklas /. ssh / id_rsa ',' keyphrase '=> ",' agent '=>",' db_role '=> true,],], 

Vous avez maintenant un nom d'application et un serveur sur lequel déployer votre application. Cette configuration utilise l'authentification par clé SSH, mais vous pouvez également vous connecter avec un nom d'utilisateur et un mot de passe. Pour obtenir un nom d'utilisateur et un mot de passe, définissez 'clé' => ". L'outil stockera les informations d'identification sur votre ordinateur local et les utilisera à chaque fois par la suite. Je ne recommande pas de définir un nom d'utilisateur et un mot de passe dans le fichier de configuration, car vous ne voulez jamais que les informations d'identification soient enregistrées dans votre référentiel..

Ce que vous devriez maintenant faire est de changer la connexion par défaut sur laquelle vous déployez. Le réglage par défaut de la production n'est pas idéal. Vous ne voulez pas passer à la production par accident. Donc, dans le même fichier, cherchez le défaut clé et changer la valeur à mise en scène au lieu.

'default' => ['staging'],

Le nom de l'application elle-même n'est pas si important. Mais si vous ne spécifiez pas de dossier dans lequel déployer, il l’utilisera comme nom de dossier dans le répertoire racine. Par défaut, la racine est définie sur / home / www. Avec ce nom d’application, il sera déployé sur / home / www / my-deployable-app. Si vous voulez changer votre répertoire racine, vous pouvez le changer en remote.php.

// se déploie dans / var / www / my-deployable-app / 'répertoire_racine' => '/ var / www /',

Dans le même fichier, vous pouvez remplacer le nom de l'application et spécifier un répertoire pour votre application..

// se déploie sur / var / www / tutsplus-tutorial 'app_directory' => 'tutsplus-tutorial', 

Vous avez maintenant un destinataire du déploiement, mais vous devez également configurer l'emplacement de votre code afin qu'il puisse être récupéré. Pour ce faire, vous devez configurer votre référentiel distant dans scm.php. Par défaut, il utilise Git, mais il supporte également SVN. Vous lui indiquez l'adresse de notre référentiel et vous fournissez les informations d'identification si nécessaire. Je vous suggère d'utiliser l'authentification par clé SSH ici également et de laisser le nom d'utilisateur et le mot de passe vides.

'repository' => '[email protected]: propriétaire / nom.git', 'username' => ", 'password' =>", 'branch' => 'master',

Puisque vous avez ajouté une connexion au serveur de production, vous souhaitez déployer la branche principale..

Configuration spécifique à la connexion et aux étapes

Dans la plupart des cas, vous ne souhaitez pas utiliser la même option de configuration pour toutes vos connexions ou étapes. Supposons, par exemple, que vous souhaitiez déployer une autre branche dans l'environnement de transfert. Rocketeer vous permet de remplacer les valeurs de configuration pour les connexions et les étapes en utilisant config.php. Pour déployer une branche appelée mise en scène sur votre connexion intermédiaire, vous procédez comme suit:

'on' => ['connections' => ['staging' => ['scm' => ['branch' => 'staging',]],],

Il utilise un tableau imbriqué pour remplacer les valeurs de configuration. Sous le mise en scène clé, recherchez la clé correspondante dans le fichier que vous souhaitez modifier. Dans ce cas c'est branche dans scm.php.

Déployer, soulever!

Vous avez maintenant tout mis en place pour réussir votre déploiement. Vous n'avez pas satisfait à vos exigences pour un déploiement complet, mais cela suffit pour que votre application soit clonée sur votre serveur et servie par les utilisateurs finaux. Tout d'abord, vous pouvez exécuter le vérifier stratégie pour voir si votre serveur répond aux exigences.

chèque de rocketeer

Si tout va bien, vous pouvez déployer en exécutant:

$ rocketeer deploy

Comme il s’agissait de votre premier déploiement, Rocketeer veillera à ce que tout soit à la hauteur. L'outil crée les répertoires dont il a besoin et dans lequel notre application vivra. Si tout se passe bien, vous devez disposer d'une version complète de votre application sur le serveur..

Si vous avez modifié la connexion par défaut en stockage intermédiaire dans la section précédente, elle sera toujours déployée sur le stockage intermédiaire. C'est, bien sûr, à moins que vous ne lui disiez de se déployer ailleurs. Lorsque vous souhaitez déployer sur une ou plusieurs connexions, vous utilisez le --sur commutateur.

# Déployer vers la production $ rocketeer deploy --on = "production" # Déployer vers la mise en scène et la production $ rocketeer deploy --on = "staging, production"

Vous voulez voir ce qui va se passer sur votre serveur une fois que vous avez appuyé sur le bouton? Utilisez le --faire semblant drapeau pour laisser l'outil vous dire ce qu'il va exécuter sur le serveur.

$ rocketeer deploy --pretend

Houston, nous avons un problème. Nous avons besoin d'un retour en arrière.

Malheureusement, nous devons prendre en charge les déploiements qui gênent les fonctionnalités ou causent des ravages dans l’infrastructure. Ensuite, vous devez effectuer une restauration rapide de votre dernière version. Heureusement, il s’agit d’une opération simple. Il suffit d’exécuter la commande suivante:

$ restauration de rocketeer

Comme il stocke un certain nombre de versions, effectuer une restauration est rapide. Cela change le lien symbolique de actuel vers la version précédente.

Répertoires partagés

Configurer des répertoires partagés est simple: ajoutez-les simplement à partagé tableau trouvé dans remote.php. Rocketeer créera et liera ces dossiers pour vous dans les déploiements suivants. Les chemins spécifiés doivent être relatifs à votre dossier racine..

'shared' => ['storage / logs', 'storage / sessions', 'storage / uploads', '.env',],

Répertoires en écriture

La plupart des répertoires partagés auront également besoin du serveur Web pour pouvoir y écrire. L'écriture de journaux, de sessions ou de téléchargements de fichiers est souvent une tâche exécutée par n'importe quelle application. Ceux-ci vous ajoutez à la permissions.files tableau dans remote.php.

'permissions' => ['files' => ['storage / sessions', 'storage / logs', 'storage / uploads',], // […]],

Installer ou mettre à jour des dépendances

L'installation ou la mise à jour des dépendances est nécessaire si l'application s'appuie sur un type de dépendance. L'outil est fourni avec le support des gestionnaires de paquets les plus populaires. Il n'est pas nécessaire de configurer quoi que ce soit si vous avez la configuration par défaut pour eux. Il détectera et installera ou mettra à jour les dépendances pour CompositeurNpmTonnelle et Bundler. La stratégie par défaut pour les dépendances est réglé sur Polyglotte. C’est l’outil de détection et d’installation des dépendances pour les différents gestionnaires de paquets..

Mais disons que vous voulez installer toutes les dépendances sur mise en scène, et l'outil utilise le --non-dev drapeau par défaut. Peut-être souhaitez-vous installer PHPUnit pour exécuter des tests, ce qui est une dépendance de développement. Dans strategies.php, vous pouvez trouver le compositeur key, qui indique à l'outil comment exécuter Composer. Vous pouvez alors remplacer ceci dans config.php:

utilisez Rocketeer \ Binaries \ PackageManagers \ Composer; // […] 'on' => [// […] 'connections' => ['staging' => ['strategies' => ['composer' => ['install' => function (Composer $ composer , $ tâche) retour $ compositeur-> install ([], ['--no-interaction' => null, '--prefer-dist' => null]); ],],]],,

Migrations de bases de données

La migration des bases de données est souvent quelque chose que vous souhaitez faire lorsque vous avez une version complète, juste avant qu'elle ne crée un lien symbolique vers la version actuelle. Quel que soit l'outil que vous utilisiez, vous pouvez lui dire de courir avant le deploy.before-symlink. Ce crochet n'est pas un crochet régulier, mais un crochet interne. Vous devez ensuite l'enregistrer ailleurs que hooks.php. Vous pouvez faire ceci dans events.php, que vous pouvez créer s'il n'existe pas déjà.

utilisez Rocketeer \ Facades \ Rocketeer; // Laravel Rocketeer :: addTaskListeners ('deploy', 'before-symlink', function ($ task) $ task-> runForCurrentRelease ('php artisan migrate');); // Symfony2 Rocketeer :: addTaskListeners ('deploy', 'before-symlink', function ($ task) $ task-> runForCurrentRelease ('doctrine php app / console: migrations: migrate');); // Doctrine autonome Rocketeer :: addTaskListeners ('deploy', 'before-symlink', function ($ task) $ task-> runForCurrentRelease ('doctrine migrations: migrate --no-interaction');); 

Tests en cours

L'exécution de tests dans un processus de déploiement est un excellent moyen de s'assurer qu'aucun code ou test défectueux ne glisse entre les mailles du filet. Par défaut, l'outil utilise PHPUnit, et vous pouvez accrocher le programme d'exécution de test à exécuter après l'installation ou la mise à jour des dépendances..

'after' => ['setup' => [], 'deploy' => [], 'dependencies' => ['test'], 'cleanup' => [],],

Nous devrions maintenant voir qu'il exécute PHPUnit sur chaque déploiement, et en cas d'échec des tests, il sera abandonné. Assurez-vous de voir la sortie, sinon le problème pourrait être de trouver un binaire PHPUnit ou votre suite de tests..

staging / 0 | ---- Test (exécute les tests sur le serveur et affiche le résultat) déclenché par des dépendances.after staging / 0 | ------ Test / Phpunit (exécute les tests avec PHPUnit) $ cd / var / www / my-deployable-app / releases / 20160129220251 $ / var / www / my-deployable-app / releases / 20160129220251 / vendor / bin / phpunit - arrêt-sur-une-erreur [[email protected]] mise en scène) PHPUnit 4.8.21 par Sebastian Bergmann et ses contributeurs. [[email protected]] (mise en attente) [[email protected]] (mise en attente). [[email protected]] (stockage intermédiaire) Temps: 4,79 secondes, mémoire: 6,00 Mo [[email protected]] (stockage intermédiaire) OK (1 test, 1 assertion) [[email protected]] (staging) staging / 0 | =====> Tests réussis

Outils de construction frontaux

Souvent, nos applications ne sont pas uniquement un back-end, à moins qu’il s’agisse d’une API REST, par exemple. Exécuter des outils de construction pour notre front-end est une tâche courante avec des outils tels que GrognementGorgée ou Webpack. Faire de cette partie de notre processus de déploiement n’est rien de mieux que d’utiliser un hook pour exécuter les commandes telles que:

'after' => ['setup' => [], 'deploy' => [], 'dependencies' => ['gulp build'], 'cleanup' => [],],

Un front-end s'appuie souvent aussi sur des dépendances, alors lancez les outils après les avoir installés ou mis à jour..

Conseils & Astuces

Exécution des mises à jour

Si vous ne souhaitez pas créer de nouvelle version lors du déploiement, vous avez la possibilité d'exécuter une mise à jour. Soyez prudent lorsque vous effectuez cette opération, car vous ne pourrez pas revenir à la version précédente, mais uniquement à la version précédente. Mais c’est un moyen simple et rapide de mettre à jour votre application avec les dernières modifications avec:

mise à jour de $ rocketeer

Tâches locales

Parfois, il peut être intéressant d’exécuter des tâches dans votre environnement local. Supposons que vous souhaitiez exécuter une vérification PHPCS ou créer vos actifs statiques et les télécharger sur le serveur, supprimant ainsi le besoin de certains fichiers binaires sur le serveur. Si vous créez une classe de tâches, vous pouvez définir la variable protégée. $ local à vrai.

la classe MyTask étend Rocketeer \ Abstracts \ AbstractTask protected $ local = true; // […]

Conclusion

Le processus de déploiement est une partie importante du cycle de vie d'une application. Des outils comme Rocketeer vous permettent facilement d’en faire une affaire simple. Cela est particulièrement vrai lorsque vous l'utilisez pour une application PHP car elle s'intègre si bien avec elle..

Pour ceux d'entre vous qui débutent avec PHP ou qui souhaitent développer leurs connaissances, leur site ou leurs applications avec des extensions, nous pouvons étudier de nombreuses choses sur Envato Market..

Écrire un tutoriel d'introduction à Rocketeer s'est avéré une tâche difficile. L'outil est tellement flexible qu'il n'est pas facile de tracer des lignes pour s'arrêter. J'espère avoir compris les possibilités d'utilisation de cet outil et ses avantages pour vous et votre application. Si vous souhaitez approfondir, je suggère de lire la documentation complète. Il y a beaucoup plus à l'outil que ce que je pourrais couvrir dans cet article.