Le site collaboratif Goood! – Gratuit, Libre, Indépendant

What a teasing in the url.

L’idée générale

2x09_0455-2-1

vualà vualà

On voulait que notre site, il reflète un peu ce que l’on est, congruence, tussah tussah.

Du coup, on s’est dit que ce qui serait rudement chouette, c’est qu’il soit simple pour tout le monde, pour les lecteurs et pour ceux qui veulent contribuer à la construction.

Dans la boîte, chacun peut s’occuper de ce qu’il lui plaît et lui tient à coeur, pour le site, c’est un peu tout pareil !

On a donc mis en place un mode collaboratif permettant à tout le monde, même Célia (qui est commerciale de profession), d’effectuer une modification du développement à la production, et ce, sans rien installer !

C’est fou ça hein ?

L’open-source et la gratuité

Du coup , pour notre site web, nous avons fait le choix d’utiliser Github pour le stockage des sources, vu que nous n’avons pas particulièrement de données sensibles, et qu’on aime assez le partage, on a créé 2 dépôts, l’un pour le développement, l’autre pour la production.

Sont accessibles par ici

github-octocat

L’hébergement du site de l’internet

On utilise GitHub Pages pour l’hébergement, GitHub Pages permet d’héberger des pages directement depuis un dépôt github.

Du coup, on a une branche gh-pages, sur notre dépôt de développement, et la même chose sur celui de production, et tout le code qui y est présent, correspond aux sources de notre site.

Donc lorsque l’on veut déployer, on prend les sources, on les transforme, on met ce que l’on désire rendre dans un répertoire spécifique (dist pour nous) et on commit celui-ci sous gh-pages.

Le côté supa pratique, c’est que du coup github nous permet d’héberger le code de notre application et le site.

pouces-31121573

#sourire #vraimenttropbien

Déploiement continu straight to the beta

On voulait que tout le monde puisse voir ses modifications, du coup, de base, vu que notre site est sous github-pages, ça implique d’avoir l’environnement en local pour compiler et déployer les modifications sur github-pages.

Du coup ça demande d’installer pas mal de choses, et ce n’est pas super pratique.

On a donc décidé d’essayer Travis-ci.

Le gros avantage de Travis, c’est qu’il s’intègre super bien avec github, il existe 2 versions de Travis, une version gratuite, pour les dépôts publics : travis-ci.org ainsi qu’une version payante, pour les dépôts privés : travis-ci.com.

Une fois celui-ci intégré, il est possible de le configurer en ajoutant un fichier de configuration à la racine du projet : travis.yml, fichier dans lequel on peut définir un tas de choses, comme la suite d’opération à jouer, le type de serveur et de serveur web qu’il doit instancier en fonction de notre langage, les branches à build, etc.

Faire commit Travis sur Git

La partie un poil plus complexe, est de pouvoir le faire commit directement sur github, où il faut définir une clé ssh git, chiffré pour travis en veillant à bien à être sur un système d’exploitation UNIX.

Pour chiffrer, je suis passé par le client travis, c’est un petit outil écrit en ruby, disponible dans les gems (les paquets sous ruby) qui nous permet de se connecter via la console sur .com ou .org, et de réaliser certaines opérations, comme du coup d’encrypter la clé ssh.

add-color-step-7

Une fois celle-ci chiffrée, ajoutée au contrôle de code source et dans les paramètres de github, il est possible de jouer une commande openssl fournie par l’outil de chiffrement nous permettant de nous identifier, celle-ci ressemble à cela : openssl aes-256-cbc -K $encrypted_65e126d10998_key -iv $encrypted_65e126d10998_iv -in deploy_key.enc -out deploy_key -d

Il s’agit ici du code d’identification de la clé ssh créée ainsi que du nom de la clé, dans mon cas, celle-ci se nommait « deploy_key ».

And voilà, la CI peut commiter comme bon nous semble.


Concrètement pour un utilisateur, ça implique juste d’avoir à modifier un fichier markdown et de le commit, pour que travis s’occupe de jouer tout cela lui-même.

Déploiement en production

On s’est pas mal creusé la tête avec BB sur le procédé de mise en production.

Nous avions besoin que tout le monde puisse tester ses modifications en béta, et déployer en production ses modifications si cela lui semble bon.

Nous sommes ainsi parti sur un système de la simplicitude, chaque build sur la béta génère un numéro de version, accessible simplement par tout le monde.

Et il suffit de copier celui-ci, dans une branche du dépôt de production, à la place de l’ancien numéro, pour lancer la mise à jour de la production à partir de la béta.

Ici il en va de même, nous avons relié un travis qui joue des scripts shells de vérification de numéro de version, récupération des sources et commit.

Ya une fote, michel tu peux modifier l’site ?? – Modifier le site

L’un des soucis fréquent sur les sites internets, c’est la mise à jour de celui-ci.

En effet, ça coûte peu d’écrire les contenus directement dans les fichiers htmls, mais ça coûte bien plus d’avoir un backoffice dédié, qui permet de modifier le contenu du site, de le stocker quelque part et d’avoir toutes les opérations que l’on nomme de CRUD dans le jargon informatique (CREAD, READ, UPDATE, DELETE).

En revanche, d’avoir le contenu écrit dans les pages html, ça demande à s’y connaître potentiellement un peu en html, et surtout, d’avoir à demander aux développeurs de s’en occuper en général.

Ici, nous sommes donc passé sur un système hybride, où nos contenus dynamiques sont dans des fichiers .markdown, cela nous permet d’ajouter dynamiquement du contenu, ainsi que d’avoir un fichier .markdown par collaborateur, par événement, par formation…

Et ainsi tout le monde peut faire ses modifications sur ce qui le concerne, en respectant la nomenclature du fichier.

Les propriétés sont en YAML, dans le cas d’un événement, pour définir son titre, sa date, son contenu,etc.

Et le reste du fichier permet d’insérer du markdown libre, c’est particulièrement utile dans les pages volumineuses, comme pour nos formations.

Le site dynamique

flashdvd

Ainsi à l’heure actuelle, on a bon nombre de collaborateurs qui se sont créé un compte git, qui ont commit, fait diverses modifications, et on a un site à jour, sans goulot d’étranglement, un peu comme ce que l’on essaie de faire sur toutes les parties de l’entreprise enfét.

Dukoo, si vous voulez nous rencontrer, on a notre agenda en ligne, et maintenu par tout le monde.

Cédric,

Just meh

 

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s