DEV Community: Akecel

Commenter son code, c’est douter de son talent ?

Akecel — Thu, 01 Oct 2020 12:55:37 +0000

Quand j’ai commencé à coder sérieusement en voulant en faire mon métier (et c’était y’a pas si longtemps) le monde du développement était bien différent, mais une chose, essentielle et commune à tous les langages était déjà présente, et ce depuis bien longtemps. Les commentaires.

Évidemment commenter son code c’est essentiel, du moins c’est ce qu’on nous rabâche très rapidement quand on commence à créé de réelles applications. Si chaque développeur gagnait un euro à chaque fois qu’on lui parle de commentaires, il n’y en aurait sûrement plus beaucoup en activité… (de développeurs j’entends)

Et bien sûr, au bout de quelques temps on comprend facilement leur intérêt et lors de nos premières code legacy, on les vénères. Mais il me semble important de revenir dessus et d’expliquer à quoi ils servent réellement, comment on doit les utiliser mais aussi pourquoi ils peuvent poser problème.

Pourquoi faire ?

C’est bateau mais oui les commentaires ont une utilité et il est important pour la suite de revenir dessus et d’essayer de ne rien oublier, et avec un peu de chance tu apprendras peut-être quelque chose.

Tout d’abord, le caractère informatif. Pour être totalement honnête c’est clairement sa seule utilité, donner des informations. Mais c’est la que le champs des possibles s’élargit. Pour qui ou quoi es-ce informatifs ? Et surtout quelles sont ces informations ?

On va commencer simple, les informations pour les développeurs, que ce soit toi dans un an ou n’importe quel autres dev qui doit intervenir sur ton code quelques temps plus tard.

On peut y retrouver de nombreuses informations différentes:

Auteur du fichier
Âge du fichier
Le copyright
L’utilité d’une classe
La version d’une classe
Le fonctionnement d’une méthode
Des précisions sur des choix de développement
Etc …

Bien sûr c’est non exhaustif et il est en vérité totalement possible d’écrire à peu près ce que tu veux tant que ça a une importance.

Mais c’est pas tout, ces mêmes informations peuvent servir à quelqu’un d’autre, enfin non ça reste utile à un développeur mais par un autre biais.. La documentation et la couverture de code.

Grâce à ces mêmes commentaires il est possible, comme je l’ai dit, de stipuler des informations sur des classes ou des méthodes qui peuvent être réutilisées par des scripts pour générer automatiquement des documentations complètes de ton application (PhpDoc, JsDoc, JavaDoc etc).

En plus de donner une information directe au développeur qui lit ton code, ta documentation offre une vision générale de l’application. Il est par exemple possible de préciser quels paramètres prend ta méthode en entrée et ce qu’on attend en sortie.

Ensuite viens les tests, on en entend parler autant voir plus que les commentaires et pour cause c’est super important (on y reviendra sûrement un jour) Et de la est née un besoin, la couverture de code. Cela permet de savoir à quel point ton application est testé, et pour cela il existe des scripts. Et encore une fois ces scripts on besoin de…..? COMMENTAIRES.

Bravo au deux au premier rang qui lisent encore.

Pour résumer, tes commentaires peuvent te servir à toi, aux développeurs qui viendront après, à créé une documentation complète et aussi à vérifier à quel point ton code est testé ou non (et donc prouver la viabilité à long terme de ton application).

Je pense qu’a ce niveau, et si ce n’était pas encore le cas. Tu es convaincu de l’utilité de commenter son code.

Mais du coup, es-ce qu’il y a une bonne façon de commenter ?

Comment faire ?

Pour répondre à ta super question. Oui, il y à de bonnes pratiques. Il existe plusieurs “types” de commentaires se différencient par leur place dans le fichier et par les informations qu’ils contiennent.

Faisons une petite liste avec des exemples :

Le commentaire de fichier :

Il sert à stipuler les informations générales du fichier, son auteur ou son nom par exemple.

/*
 * UserController.php
 *
 * @author Axel.
 */

namespace App\Http\Controllers\Api\User;

use App\Http\Controllers;

class UserController extends ApiController {

....

}

Le commentaire de classe :

Les informations propres à une classe, son utilité et pourquoi pas d’autres informations comme sa version d’implémentation, le développeur en charge de son développement etc …

/*
 * Logique controller des utlisateur
 * 
 * @class UserController
 * @since 3.1
 */
class UserController extends ApiController {

....

}

Le commentaire de méthode :

Tout ce qui concerne une méthode, son fonctionnement, son utilité, ses paramètres etc …

 /**
  * Afficher la liste des utilisateur.
  * @param  \Illuminate\Http\Request  $request
  * @param  App\Models\User $user
  * @return \Illuminate\Http\Response
  */

  public function index(Request $request, User $user) {
      ...
  }

Le commentaire de précision :

Ce sont les petits commentaires, directement écrit à l’intérieur du code, servant à justifier un choix ou à apporter des précisions sur un bout de code en particulier.

public function index(Request $request, User $user) {  
  // On autorise cette méthode qu'au token administrateur
  $this->authorize('adminManage', $user);  
  // On récupère la collection d'utilisateurs avec les paramètres
  return new UserCollection(User::with($this->withs)->get());
}

Bien sur, ce ne sont que des exemples, rien est vraiment gravé dans le marbre et les syntaxes et l’utilisation de ces différents commentaires peuvent varier selon le langage ou l’équipe dans laquelle tu bosse.

Que des avantages ?

Jusqu’ici on pourrait se dire que les commentaires, en plus d’être utiles et presque indispensables n’ont que des avantages, mais il n’en ai rien.

Il existe bien des inconvénients. De nombreux même, et c’est bien normal, plus un outil semble indispensable plus il est utilisé, parfois bien, et parfois mal.

Quand on y réfléchit un peu plus longuement, on se rend vite compte que de nombreux commentaires sont souvent facultatifs, ceux de “précisions” par exemple : Ils sont, la plupart du temps, un aveux de faiblesse.

“Mon code n’est pas très clair, je dois le commenter”.

Être conscient des problèmes de son code est une première étape, reste ensuite à apprendre comment nettoyer son code, le rendre plus lisible et parfois sacrifier la facilité pour la maintenabilité.

Regarde les commentaires de précision que je t’ai donné en exemple tout à l’heure :

public function index(Request $request, User $user) {  
  // On autorise cette méthode qu'au token administrateur
  $this->authorize('adminManage', $user);  
  // On récupère la collection d'utilisateurs avec les paramètres
  return new UserCollection(User::with($this->withs)->get());
}

Sont-ils réellement utiles ? Qu’elles informations apportent-ils que le code ne contient pas déjà ?

De plus, avec les documentations auto-générées et la couverture de code, on se retrouve très souvent avec des commentaires qui n’ont pas d’autre utilité que celle là, qui prennent parfois plus de place que le code lui même et qui rendent le code illisible.

Conclusion

Il faut donc apprendre à différencier un bon, d’un mauvais commentaire, savoir jauger la pertinence de certains et le superflus d’autres. Et surtout il faut être conscient de ces problématiques.

Bref, si le code parfait existait, il n’aurait pas besoin d’être commenté, et le commentaire parfait, lui, est celui qui n’a pas besoin d’être écrit.

Mais c’est pas non plus une raison pour pas commenter ton code compris ?

La solitude des devs PHP dans les écoles du Web

Akecel — Thu, 01 Oct 2020 12:55:28 +0000

Vois-tu, j’entre cette année en 1ere année de Master. J’ai donc derrière moi, trois années d’études dans le milieu de l’informatique, de la programmation et du web. Et… forcé de constater, dans certaines formations, le PHP est aujourd’hui fortement délaissé au dépend de JavaScript et de ces différentes utilisations.

Évidemment ce n’est pas une généralité, d’ailleurs c’est uniquement dans les formations privées que c’est le cas, mais bien sûr ce sont en général les formations les plus professionnalisante. Au contraire dans l’enseignement public, en BTS, DUT ou en Licence, le PHP garde bonne réputation et sert encore aujourd’hui de “premier langage de programmation web” pour les futurs développeurs.

Cela m’a fait donc me poser de nombreuses questions à ce propos… Et si tu te les poses aussi, je vais essayer d’y répondre.

L’effet de mode

Évidemment quand on parle de Node.js on est obligé de parler de son explosion, cette technologie est passée, en 10 ans, d’inexistante aux “Must Know” du développeur branché. Bon je ne vais pas être de mauvaise fois, il y a des raisons et Node à ces avantages mais est-ce que cela justifie un tel engouement ? (Oui surement).

Le point intéressant pour notre sujet c’est, je pense, que Node.js a très rapidement eu une réputation de technologie “Cool et moderne”. De là , toute Startup ou agence se lançant sur le marché et qui avait besoin de montrer qu’elle était “jeune et dynamique” se lançait directement sur Node.js (en fait Macron c’est un président asynchrone?).

Attention, ne me fais pas dire ce que j’ai pas dit, Node est très performant et il a ses avantages, ses cas d’utilisations, comme toutes les technologie et les langages. Mais je suis persuadé que de nombreuses jeunes boites ont décidées assez arbitrairement de construire leur stack autour de Node.

Évidement les développeurs eux même ont suivis cette mode. À cette époque je codais mes toutes premières lignes en C++ donc j’étais encore loin du Web…

Mais j’imagine que n’importe quel développeur, voyant cette chimère permettant de faire du JavaScript coté serveur arrivée vers lui, s’est senti pousser des ailes et que la plupart, consciemment ou non, ont compris que cette technologie ferait partie intégrante du paysage Web dans les années futures. (Bonne pioche)

On se retrouve donc avec de plus en plus de développeurs curieux face à une nouvelle technologie et un marché de l’emploi ou Node fleurit comme les marguerites dans le jardin de ma grand mère...

S’adapter au marché

Et c’est LÀ qu’entre en jeux les écoles du Web. Pour n’importe qu’elle école spécialisée dans le Web, son but c’est de faire de l’argent. On va pas se mentir hein, je citerai aucun nom et je critiquerai même pas ce système car il ne me choque pas vraiment. Car justement, pour faire beaucoup d’argent, il doivent forger de bons développeurs, de bons développeurs qui rendront heureux les employeurs qui eux même donneront de la valeur aux diplômes et surtout à l’école.

Et donc pour ça, ces écoles doivent s’adapter au marché. Chose évidement très complexe dans un monde ou le Web est plus indécis qu’un chat devant une porte.

Mais en vérité elles s’en sortent pas trop mal, mais cela à des conséquences et suivre “la tendance générale” est toujours plus simple que d’adapter un programme de trois ans chaque années en fonction des fluctuations du marché.

Du coup, dans la plupart de ces formations on se retrouve avec quelques cours de PHP, un peu forcés, souvent “bourre crane” et qui arrivent rarement à trouver leur public malgré la forte présence de PHP sur le marché. Puis viens ensuite des cours de JavaScript, de React, d'Angular, de Node.js et là, les futurs développeurs y voit une échappatoire au PHP. On se retrouve donc avec 3/4 des dev des promotions spécialisés en JS, front ou back et avec un tout petit échantillon préférant le PHP et se faisant honteusement discriminer par les autres (non, j’ai absolument aucun traumatisme)

De toutes ces choses nait un triptyque infernal provoquant lui même un cercle vicieux :

Le marché recherche du JS alors les écoles forment du JS donc les Dev pensent que le JS est indispensable et donc lancent des entreprises et recherchent du JS.

Et le public dans tout ça ?

À vrai dire, je ne sais pas réellement pourquoi les formations publiques insistent moins sur le JavaScript que les privées. On pourrait facilement penser que c’est car les programmes sont réalisés par des vieux de la vieille qui sont, pour la plupart pas des développeurs mais bien des ingénieurs qui eux sont beaucoup moins enclins à suivre une tendance, du moins pas sur des laps de temps aussi court.

Mais soyons honnête on ne sait pas vraiment et il est impossible de savoir aujourd’hui si c’est le bon choix ou non. Ni même de savoir lequel des deux types de formations créera les meilleurs développeurs sur le long terme. Tout ce qui est sur, c’est que cela offre un éventail de possibilités à l’étudiant et surtout une alternative aux formations privées qui sont presque toujours payantes, du moins les première années (on en reparlera dans un futur article).

Conclusion

On sait que la place du JavaScript dans le marché des développeur et son expansion continuelle est du à un cercle vicieux entre les écoles, les développeurs et la mode.. Mais après tout est-ce que c’est grave ?

Non.

Ce sont, je pense, deux facettes d’une même pièce et il me semble normal aujourd’hui de dire qu’une formation ne doit pas tant nous apprendre un langage ou une techno, mais bien nous apprendre des méthodologies, des bons réflexes et une gymnastique d’esprit qui permettront au développeur d’apprendre tout au long de sa carrière.

Le marché changera, encore et encore. Le JavaScript sera un jour considéré comme un langage pré-historique et ce jour là quelqu’un se posera les mêmes questions que moi aujourd’hui, mais avec d’autres langages. Dans un milieu évoluant aussi vite que le notre, la véritable valeur d’un dev n’est pas le nombre de langages qu’il maitrise ni même son langage de prédilection mais plutôt sa curiosité et son envie de découvrir de nouvelles technologies.

Et oui, malheureusement, on ne peut s’empêcher d’avoir un langage favori. On peut donc, comme moi, être spécialisé PHP, se retrouver entouré de développeur Javascript et donc… Se sentir un peu seul.

Mais il faut rester conscient qu’aucun langage n’a réellement plus de valeur qu’un autre, ils ont tous leurs avantages, leurs inconvénients et leurs cas d’utilisations.

La vraie force d’un dev c’est de savoir jongler avec ces langages et technologies en fonction de ses besoins, pas de connaitre sur le bout des doigts le langage le plus tendance ou le plus compliqué.

La synesthésie chez les développeurs

Akecel — Thu, 01 Oct 2020 12:55:17 +0000

Ces dernière années j’ai entendu plusieurs fois parler de synesthésie et bien que le sujet ne m’intéressait pas plus que ça, j’ai fini par tomber sur un article (que je ne retrouve plus aujourd’hui) qui traitait de ce trouble neurologique et qui m’a passionné.

Je t’arrête tout de suite, je suis absolument pas atteint de synesthésie. Du moins pas que je sache, et après avoir lu pas mal de chose sur le sujet, je pense que je le saurais.

Et oui ça fait exactement 3 fois que je te cite le mots “synesthésie” mais j’ai toujours pas expliqué ce que c’était. Et si tu n’as jamais entendu parler de ça tu dois me prendre pour un sacré relou (j’adore ça), donc bref, trêve de blabla, on est partis.

Synesthésie

D’après ce merveilleux outil qu’est Wikipédia, la synesthésie c’est :

“La synesthésie est un phénomène neurologique par lequel deux ou plusieurs sens sont associés de manière durable”

Alors pour une fois c’est assez clair, mais pour bien se rendre compte de la chose on va donner des exemples, il existe dans ce monde, des personne qui, quand elles voient des lettres de l’alphabet associent chacune de ces lettres à une couleur. Effectivement pour les non-synesthètes, ça peut paraître extrêmement étrange, et pour cause. Mais cela existe bel et bien, et c’est mine de rien assez répandu. Enfin, d’après les études, ce serait une personne sur 24 qui serait concerné (ça fait 4%), mais aujourd’hui, avec internet et les réseaux sociaux, il est beaucoup plus commun d’en entendre parler.

Il y a d’ailleurs eu il n’y a pas si longtemps une vague d’articles sur la synesthésie après le buzz d’un gif sur twitter que tu as surement vu passer.

À cet instant de nombreuses personnes se sont renseignées sur ce phénomène et beaucoup se sont découvert synesthète. C’est l’article de l’un d’eux qui avait piqué ma curiosité à l’époque.

Ce qu’il faut bien comprendre c’est que ce fameux gif n’est pas réellement un “test de synesthésie”, déjà car il existe de nombreuses formes différentes de ce phénomène, mais aussi, et surtout, parce qu’en fait, ce qui se cache derrière ce gif n’est pas réellement de la synesthésie, mais plutôt une association d’idées mêlé à une dissonance sensorielle, notre cerveau essai de combler un vide, tout simplement. Évidemment un synesthète entendra plus facilement le bruit, mais l’entendre de fait pas de toi un synesthète.

Comme je te l’ai dit plus haut, il existe plusieurs formes de synesthésies, mais aussi plusieurs catégories :

Synesthésie bimodale :

C’est la synesthésie qui croise deux sens, généralement unidirectionnel, par exemple, associer une couleur à un son (mais pas l’inverse).

Synesthésie multimodale :

La même que la bimodale sauf que cette fois-ci c’est bidirectionnel, par exemple, les formes évoquent de la musique et inversement.

Synesthésie cognitive :

C’est celle ci qui va nous intéresser ici. C’est aussi la plus compliquée et la plus abstraite, le type répandu est celui où une couleur est associée à une lettre. Elle est aussi appelée “idéoesthésie”.

On va s’attarder sur deux types de cette dernière catégorie, la synesthésie cognitive et spatio-temporelle.

Dans ces deux types, un peu similaires, une carte mentale entre en jeux. D’un côté pour les nombres et l’autre pour le temps. Que ce soit un repère orthonormé pour se représenter les nombres ou bien un ruban pour “voir” le temps. On se retrouve ici avec une projection mentale pour se représenter quelque chose d’abstrait au premier abord mais de profondément factuel.

Tu vois où je veux en venir ?

Chez un développeur

Je pense qu’on sera tous d’accord pour dire qu’un développeur, en plus évidemment d’utiliser des langages et de connaître des méthodologies, doit avoir une certaine gymnastique d’esprit. Que ce soit pour préparer l’architecture d’une application, pour modéliser une base de données, pour intégrer de façon optimale une interface ou même pour penser et mettre en place une pipeline de CI/CD.

Bref tu l’aura compris, savoir se représenter des systèmes complexes mentalement est une compétence extrêmement intéressante, et bien qu’évidemment, elle ne soit pas indispensable, on ne peut nier son utilité.

Imagine maintenant un développeur synesthète. Imagine la facilité avec laquelle il pourrait se représenter toutes ces choses de façon intuitive, pratiquement inconsciente et surtout, imagine la facilité qu’il pourrait avoir pour certaines tâches par rapport “aux commun des mortels”.

J’ai essayé de me renseigner et de trouver des développeurs synesthètes et malheureusement je n’en ai pas trouvé. Donc si c’est ton cas à toi qui lis ça, hésites surtout pas ! Contact moi et on discutera de tout ça !

D’autre part, le seul développeur synesthète “connu” que j’ai pu trouver est Robert Cailliau, qui n’est pas n’importe qui étant donné qu’il est le co-fondateur de web. Autant vous dire que sans lui on serait pas là aujourd’hui à se poser des questions comme celle ci sur un blog.

Lui, par exemple il possède une synesthésie bimodale de type Graphème / Couleur, il associe donc naturellement des lettres à des couleurs..Peut être cela l’a t’il aider dans la conception de l’hypertexte, qui sait ?

La programmation est basée sur des langages eux même possédants une syntaxe mais aussi sur une architecture que l’on peut se représenter de façon spatiale. Toutes les caractéristiques de la programmation peuvent être impactées par une forme de synesthésie.

Il y a d’ailleurs surement de nombreuses autres applications auxquelles je n’ai pas pensées ou que je ne connais même pas, mais je pense qu’on peut sans risque dire que beaucoup d’axes du développement web et de la programmation informatique en générale peuvent être influencés par ce phénomène et peuvent donc ouvrir des perspectives très intéressantes dans l’aspect méthodologique de cette discipline.

Conclusion

Est-ce qu’un développeur synesthète serait un super-dev ?

Peut-être bien mais… Il ne serait peut être pas meilleur qu’un autre, il aurait surement des facilités sur certaine tâches, mais pourrait aussi très bien avoir des difficultés sur d’autres. Ce qui est sûr c’est que je trouve intéressant de se poser la question de quelle serait la “façon de penser” optimale pour un développeur je pense que tenter de trouver une réponse à ces questions est une première étape pour mettre en place des nouvelles méthodologies qui pourraient, possiblement, régler certains problèmes que l’on retrouve dans le métier… À méditer.

Évidemment je tiens à le préciser, je ne fais absolument pas l’apologie de la synesthésie. Bien que ce trouble ne soit pas handicapant d’après les différentes sources, je ne veux parler au nom d’aucun synesthètes. Considérez cet article comme une porte ouverte à la réflexion méthodologique.

La bise !

Des scripts Shell pour déployer en une ligne

Akecel — Thu, 01 Oct 2020 12:55:03 +0000

Dans cet article on va essayer de créer un petit script de déploiement qui pourra être adapté à n’importe quel projet et qui, si tu l’utilises bien te poussera naturellement à fouiner du coté du DevOps et plus particulièrement de la Livraison continue et du Déploiement continu.

Pour ça, voila de quoi on aura besoin :

De Git (ou autre tant que ça fait le taff).
D’un serveur web (spoiler).
Pouvoir se connecter en SSH sur ce serveur.

Petit disclaimer tout de même, cet article ne s’adresse évidement pas à toute personne ayant déjà une bonne connaissance des enjeux DevOps. Je ne suis qu’un dev junior qui partage son approche légère et progressive de cette méthodologie à d’autres juniors. D’ailleurs tout cela n’est que de la vulgarisation, au yeux d’un avisé, il y aura sans doute beaucoup d’erreurs mais j’essaie simplement de trouver les mots juste pour faire passer un message, ce n’est pas toujours simple 😉

Le Shell ? Kecekecé ?

Avant tout, il faut impérativement essayer de comprendre les outils qu’on va utiliser, et le principal c’est évidement les Scripts Shell 😱. Pour t’expliquer ça je pourrais évidement simplement citer la définition Wikipédia mais d’une ; on comprend rien à ce qu’ils racontent là bas. Et de deux ; on s’en fou un peu de la définition académique.

Donc nous on va faire dans la simplicité 😎

Shell c’est un langage de script, donc un langage de programmation, qui doit être interprété, jusque la on est ok, on connait. Mais la particularité des langages de script c’est qu’ils permettent d’automatiser une succession de commandes simples (entre autres hein).

On peut donc imaginer des scripts pour tout, mais ici on va s’en servir pour coordonner et exécuter différentes commandes qui vont aboutir au déploiement de notre projet.

Git & SSH

Là c’est la début de la fin. C’est quand on commence à entendre parler de connexions SSH, de clés SSH privées ou publiques, de RSA et autre fingerprint qu’on se dit qu’on a surement quelque chose de plus constructif à faire que de lire un article ou un tuto.

Et tu n’as pas tort, mais bon c’est une étape indispensable, évidement j’espère que tes projets sont déjà gérés avec Git (ou un autre gestionnaire de versions). Si non… QU’ATTENDS-TU ?

Outre cela, tu vas aussi devoir configurer ton serveur web pour pouvoir te connecter en SSH :

$ ssh user@000.00.000.000 -p 00

Techniquement, il même possible de ne pas avoir à trifouiller des clés SSH, du moins pour le moment, tu te rendras vite compte que c’est quand même super pratique.

Partons du principe que tu as tout ça, ton projet est sur GitHub, ton serveur te permet de te connecter en SSH et toi tu continues de lire cet article alors qu’il n’y a pas eu une ligne de commande en 5 minutes.

Codons un peu

Mais pas tout de suite.

On va prendre pour exemple un répo GitHub qu’on va appeler “simple_test_repo” .

Commençons par se connecter à notre super serveur.

$ ssh user@000.00.000.000 -p 00

D’ici, allons dans notre répertoire “srv"

$ cd /srv

Maintenant nous allons créer un nouveau répertoire qu’on va appeler “src” pour les “sources”. C’est ici que notre répo git sera cloné. Ça va nous permettre de bien séparer ce qui concerne Git et la version en ligne du projet. On se donne les droits sur ce répertoire et on se rend à l’intérieur.

$ sudo mkdir src
$ sudo chown user:user src
$ cd src

A présent, on peut cloner ici notre projet (on ne configure pas encore les fichiers d’environnement du projet)

$ git clone https://github.com/user/simple_test_repo.git

On fait évidemment un petit “ls” pour vérifier que tout va bien. Et ensuite, on crée de nouveau un répertoire, cette fois-ci nommé “script” et on se rend dedans :

$ sudo mkdir scripts
$ cd scripts

Ok, maintenant on a toute notre infrastructure pour commencer nos scripts et goupiller tout ça.

Prêt pour créer ton script ? Ok let’s go 🚀

$ nano pull_and_deploy_website.sh

Maintenant il faut écrire ton script, voilà ce qu’on va mettre dedans :

!#/bin/bash -eu
cd /srv/src/simple_test_repo
git pull origin master
rsync -r . /var/www/html --exclude .git

Voilà ce que tout ça veut dire :

On commence simplement par dire à Unix qu’on va utiliser Bash, le -eu est en quelque sorte le mode strict de bash (merci à la personne qui m’a dit de le rajouter)
Ensuite on se rend dans le répertoire ou notre projet est cloné
On récupère les différentes modifications qui ont été faites
On copie uniquement les fichiers qui ont été modifiés dans le répertoire www du serveur web en excluant le dossier .git

Il y a plein de façons d’optimiser ces commandes, par exemple il est possible d’utiliser “rsync -aC” pour conserver les liens symboliques et ignorer par défaut certains fichiers. Mais on va rester dans la simplicité pour ce script là.

Pour finir on règle les permissions de ce script :

$ chmod +x pull_and_deploy_website.sh

A présent tu peux configurer les fichiers d’environnement de ton projet.

L’intérêt de tout ça, c’est de séparer proprement les fichiers qui proviennent de ton gestionnaire de versions et tes fichiers qui seront possiblement accessibles par l’utilisateur, ça offre une couche de sécurité en plus et cela t’oblige à prendre en compte ton infrastructure.

De plus pour déployer il ne te suffit plus que d’une seule ligne (après t’être connecté en SSH)

$ srv/src/scripts/pull_and_deploy_website.sh

Tu as maintenant deux copies de ton projet sur ton serveur, une directement reliée à Github avec une remote récupérant les différentes mises à jour, et une, en ligne, que tu peux mettre à jour en une seule ligne de commande, le tout de façon sécurisée.

Tu peux aussi personnaliser ton script, en créer pour plusieurs projets, y rajouter des messages de succès, pourquoi pas essayer d’y intégrer des builds, ou des tests ? Mais, tu te rendra vite compte que tu es limité… (enfin pas toi, le script)

Conclusion

Si tu as bien lu et que tu as essayé ce script en le modifiant à ta sauce, tu as sûrement compris le potentiel de ce genre de méthodes…

Et bien félicitation, tu viens de créer ta première pipeline, simple, basique (vous n'avez pas les bases), archaïque même, mais c'est une pipeline. Et si tu as compris les enjeux et objectifs de ce script, alors tu as compris ceux de la méthodologie DevOps: automatisation, sécurité et performance.

Mais du coup, comment faire pour que cela deviennent une vraie pipeline ? Et bien en fait là, on exécute à proprement parler qu'une seule tache, et pour que cela soit une vraie pipeline il en faudrait plusieurs déjà. Le minimum serait en premier lieu d'ajouter des tests, unitaires par exemple.

Ce qu'il te faut comprendre avec le CI/CD c'est les principes d'automatisation et de non régression. Pour que ton code reste fonctionnel, et que tes nouvelles fonctionnalités n'entrent pas en conflit avec les anciennes, ta pipeline doit avoir un déclencheur, un push ou un merge sur master par exemple. Ensuite et seulement ensuite une série de taches sera effectuées automatiquement à partir de ta pipeline, le plus courant étant :

Build ➡️ Test ➡️ Déploiement

Pour faire simple, une pipeline se comportera comme ton script, mais à grande échelle.

Et c'est ici qu'entre en jeu les différents outils de CI/CD, ils t'offriront un environnement pour tes pipelines, une interface graphique et des documentations indispensables. De plus ils te permettront d'affiner tes possibilités en ajoutant du Coverage, du Code Legacy et plein d'autre joyeusetés 😊

À présent, n'hésites pas à te renseigner sur ces différents outils (Gitlab CI, CircleCI, Jenkins, Travis et GitHub Action), à coder tes premiers tests unitaires, à réfléchir à différentes pipelines pour différents besoins et à te lancer dans le merveilleux monde du DevOps.

Tu peux trouver le code source de cet article ici !

Merci beaucoup à toi d’avoir lu jusqu’ici, je le répète je suis un dev junior et j’essaie de rendre le propos le plus simple possible, je suis loin d’être un grand développeur. Je suis conscient que la méthode présentée dans cet article paraîtra absurde et inutile à beaucoup de personne, mais moi, elle m’a aidé à mieux cerner certains enjeux et il me semblait important de la partager.

J’espère que cet article t'aura tout de même intéressé et je reviendrais très bientôt avec d’autres sujets 😉