Le journal

Un modèle de thèmes Bootstrap pour vos sites

Un modèle de thèmes Bootstrap pour vos sites
Vous pouvez découvrir dès aujourd’hui un nouveau thème graphique pour Kiubi.

Ce thème inaugure une nouvelle structure technique sur laquelle tous les prochains thèmes seront basés : le framework Bootstrap. Cette technologie, développée historiquement pour et par Twitter, est devenue un quasi-standard au fil des ans et offre de nombreux avantages.

Tout d’abord, ce nouveau thème est évidement mobile first, nativement responsive. Il intègre toutes les bonnes pratiques en matière de développement front-end (sémantique, accessibilité, microdata, compression du code, etc.) afin de proposer une base standardisée et nativement optimisée pour le référencement naturel.

Le framework Bootstrap étant très répandu - bons nombres de sites Kiubi l’utilisent déjà - de nombreuses ressources sont disponibles, généralement gratuitement, pour personnaliser les thèmes Bootstrap.

Vous pourrez ainsi profiter de ces ressources, tout particulièrement en matière de Design : tous les design pour Bootstrap ainsi que tous les générateurs de design sont compatibles avec ce thème.

À vous de choisir ou de construire le design qui correspond le mieux à votre site !

Ce thème inclut également toute une série de modules et de templates prêts à l'emploi utilisant les composants et widgets de Kiubi :
  • plusieurs types de billets pour présenter le contenu
  • des carrousels (contenu libre, articles du blog, produits, etc.)
  • un super-zoom pour les produits
  • des lightbox pour les photos
  • de nombreux composants de Bootstrap (jumbotrons, boutons, accordéons, etc.)
  • une galerie photos, en guise d’exemple d’utilisation de l’API
  • plusieurs templates principaux différents (avec ou sans barre latérale, en pleine largeur ou en largeur fixe, etc.)
Afin de conserver une cohérence avec Bootstrap, tous les autres widgets de Kiubi ainsi que tous les modules javascript ont été choisis et adaptés pour utiliser directement le framework, sans surcharger le thème d’éléments inutiles.

Tous ces éléments contribuent à créer un thème d'une grande qualité technique, très complet mais également facilement personnalisable.

Pour activer ce nouveau thème graphique, ce que nous conseillons pour tous les sites qui n'utilisent pas encore de thème personnalisé, rendez-vous dans la gestion de thèmes de votre console d'administration. L'activation se fait en 1 clic, ne vous en privez donc pas !

Inside Kiubi

Développer simplement son (e-)commerce de proximité

Développer simplement son (e-)commerce de proximité
Il est loin le temps où le e-commerce était opposé au commerce de proximité. Près de 9 e-commerçants sur 10 ont également une boutique physique et 2 tiers ont une clientèle très majoritairement locale.

Si proposer en ligne des services de proximité est ainsi devenu essentiel pour répondre aux exigences de ses clients, leur mise en œuvre n’est quant à elle pas toujours simple :
  • Il est nécessaire de mettre en ligne son catalogue de services ou de produits
  • Proposer un système de réservation adapté aux attentes de ses clients...
  • ... mais également aux contraintes et horaires de son magasin
  • Gérer le bon suivi des commandes
  • Organiser son stock et sa logistique en conséquence
  • Faire éventuellement communiquer les différents logiciels de l’entreprise
  • Sans oublier le mobile
Autant de ressources, et de coûts, supplémentaires à déployer pour assurer des services de qualité à ses clients.

Mais c’était sans compter sur Kiubi. Depuis la dernière mise à jour, vous disposez de nouveaux outils qui vous aideront à simplifier la mise en place de ces services. Vous pourrez ainsi faire converger les avantages du e-commerce et de la vente en magasin, pour le plus grand bonheur de vos clients. Et du vôtre.

Le click and collect

Le click and collect est un service qui permet à vos clients de commander ou de réserver des produits en ligne et de venir les retirer en magasin. Les avantages pour eux sont nombreux : gain de temps, pas de contrainte horaire, possibilité de comparer et de tester (ou goûter) le produit, économie sur les frais de livraison, etc.

Quant à vous, commerçant, le click and collect vous permettra de dynamiser le trafic de votre magasin en attirant des nouveaux clients qui ne vous connaissent pas (encore), tout en gardant un contact privilégié avec vos habitués.

Toutes les boutiques de Kiubi pourront ainsi définir directement dans leur console d’administration leurs jours et horaires d’ouverture, entre d’autres options. Vos clients seront alors libres de réserver en ligne puis de venir retirer leurs produits en magasin à la date et à l’heure qu’ils auront choisies au moment de leur commande.

La livraison de proximité

Mais ce n’est pas tout. En complément du click and collect, un nouveau mode de livraison fait son apparition : la livraison de proximité. Cette nouvelle fonctionnalité permet au commerçant de déterminer une zone de livraison précise, en fonction du code postal de ses clients. Il vous sera ainsi possible d'organiser vos livraisons uniquement dans un rayon de 10km autour de votre point de vente, par exemple.

Avec la livraison de proximité, vos clients auront l’assurance de bénéficier d’une livraison rapide, à l’heure qu’ils auront choisie.

Mieux répondre aux attentes de ses clients

Avec le click and collect et la livraison de proximité, c’est plus d’une cinquantaine d’options supplémentaires qui s’ajoutent à la gestion des commandes et à la logistique pour améliorer le confort d’achat de vos clients !

Et pour les commerçants qui ne proposeraient pas encore de vente en ligne, il est encore temps de s’y mettre ?

Les releases

Click and collect, livraison de proximité, nouvelles options de commandes, nouvelles balises

Click and collect, livraison de proximité, nouvelles options de commandes, nouvelles balises

Click and collect

Plusieurs options s’ajoutent au retrait en magasin afin de pouvoir définir les jours et heures d’ouverture de la boutique. Les clients peuvent ainsi venir retirer leurs produits en magasin à la date et à l’heure qu’ils auront choisies au moment de leur commande.

Livraison de proximité

Un nouveau mode de livraison est disponible : la livraison de proximité. Le calcul des frais de port est basé sur le code postal de la ville de livraison. La livraison de proximité inclue les mêmes options qu’un transporteur classique mais également le choix de la date et de l’heure de livraison, comme pour le Click and collect.

Seuil minimal de commande

Un seuil minimal de montant de commande a été ajouté aux transporteurs. Ainsi, un transporteur ne pourra être sélectionné qu’à partir d’un certain montant de commande. En dessous de ce seuil, le transporteur n’est pas sélectionnable à la commande.

Destinataires multiples

La configuration des emails de confirmation de commandes permet d’ajouter plusieurs destinataires.

Nouveau filtre

Un nouveau filtre de balise est disponible pour les templates : mapValue|x|y. Il permet de comparer la valeur d'une balise avec ses valeurs de références. Affiche X si la valeur est "1", "actif", "checked", "selected" ou "erreur". Affiche Y dans le cas contraire.

Grilles personnalisables dans le back-office

Le système de grille utilisé directement dans la gestion de la mise en page du back-office a été amélioré afin de le rendre personnalisable. Les thèmes graphiques peuvent ainsi inclure quatre fragments de codes HTML personnalisables qui se substituent au code des grilles disponible par défaut.

Cette mise à jour de Kiubi aura lieu mardi 25/07/2017 et nécessitera une interruption de service démarrant à 20 heures qui ne devrait pas excéder une heure.

EDIT du 25/07/2017 : La mise à jour est terminée et la plateforme est opérationnelle. Vous trouverez les fichiers nécessaires à la mise à jour sur la page dédiée à cet effet.

Le journal

Kiubi fête ses 10 ans et va de l'avant : open source et gestion de flux

Kiubi fête ses 10 ans et va de l'avant : open source et gestion de flux
C’était en février 2007 que les premiers sites Web ont pu ouvrir sur Kiubi.

Traditionnellement, pour un anniversaire aussi important, il est attendu que l’on fasse un bilan de ces 10 années d’activité.

Kiubi, c’est aujourd’hui presque un milliard de pages vues. 200 millions de visiteurs. 5 millions de transactions.

Kiubi, c’est 12 000 utilisateurs, clients, partenaires, agences web, webdesigners, artisans, industriels, commerçants, institutionnels, en France mais aussi en Belgique, au Sénégal, en Allemagne, au Japon, en Côte d'Ivoire, en Suisse, au Maghreb, au Canada, à Taïwan qui nous ont fait confiance et nous ont challengés pendant toutes ces années.

Kiubi, c’est le résultat du travail de Matthieu, Eric, Ophélie, Michael, Nicole, Télesphore, Natacha, Alexandre, Vincent, Grégory, Marc, Sébastien et tout ceux qui, de leurs petites mains, avec leur créativité, permirent de créer cette fantastique plateforme CMS.

Kiubi, c’est aussi des échecs qui nous ont permis de progresser et d’aller de l’avant.

Kiubi, c’est tout cela et nous en sommes très fier ! Mais cet anniversaire très spécial, c'est surtout pour nous l'occasion de vous parler de nos futurs projets.

Pendant 10 ans, nous avons construit avec Kiubi tout un ensemble de processus permettant de gérer et de manipuler des flux de données structurées : catalogue de produits, contenu rédactionnel, gestion de commandes, statistiques, informations clients, gabarits de mise en page, transactions bancaires, stockage de médias, outils marketing, gestion de formulaires, etc.

Parallèlement, nous avons assisté à l’émergence de nouveaux usages d’Internet. La porte c’est progressivement ouverte vers les réseaux sociaux, les marketplaces, les apps mobiles, les objets connectés, les bots conversationnels, les assistants personnels. Le classique site Web n’est donc plus depuis longtemps le seul canal sur lequel interagir avec des données via Internet.

Cependant, pour beaucoup d’entreprises, c’est vers leurs sites Web, e-commerce ou non, que convergent leurs données métiers (contenus, produits, commandes, clients, etc.). Là où les ERP (et autres POS) devraient être en charge de centraliser ces informations, leurs fortes contraintes d’interconnections les rendent très difficiles et très coûteux d’utilisation. Les sites Web, bien plus souples et standardisés, se sont alors imposés dans ce rôle qui n’était initialement pas le leur.

Notre objectif pour les années à venir sera de faire profiter à nos utilisateurs de cette convergence de données et de progressivement permettre l’utilisation des flux gérés par Kiubi dans un cadre dépassant celui d'un simple site Web pour s’ouvrir ainsi à l’ensemble de ces "nouveaux" usages.

Pour rendre cela possible, tous ces flux pourront bientôt être pilotés à 100% via nos API. Tout ce que vous pouvez faire aujourd’hui avec Kiubi, vous pourrez le faire demain à partir de n’importe quelle autre application et l’enrichir de vos propres développements.

La console d’administration restera évidemment disponible en SaaS mais sera également distribuée en version téléchargeable sous licence open source. Elle se présentera sous la forme d’une toute nouvelle application Web que vous pourrez personnaliser sur mesure, héberger là où vous le souhaitez (sur vos propres serveurs aussi bien que sur votre Raspberry), y ajouter vos développements spécifiques, la customiser selon les besoins de vos projets, l’intégrer partiellement dans d’autres applications ou d’autres CMS, etc.

Le "front-office" d’un site Web pourrait à terme devenir optionnel et être complété, voir remplacé, par des flux de données pilotés par un objet, transformés par une application tierce, publiés sur plusieurs canaux simultanément, l’ensemble orchestré par Kiubi.

Nous reviendrons bien entendu très largement sur ses évolutions tout au long des prochains mois.

Et, encore une fois (nous ne pourrons jamais vous le dire assez), merci à tous les kiubistes pour ces 10 ans de passion !

L'atelier

Les releases sans peur et sans reproche

Les releases sans peur et sans reproche
Une des grandes forces du SaaS est de s’autoriser à oublier tous les petits tracas techniques des logiciels informatiques. Le service est tout le temps disponible et accessible de n’importe où. Pas d’installation de mises à jour, pas de matériels défectueux, pas de maintenance.

Ces tracas n’ont pourtant pas disparu, ils ont simplement changé de mains.

Dès qu’un lot de nouvelles fonctionnalités est développé, c’est à nous de les installer. Les évolutions de Kiubi se font par ces petits bonds qu’on appelle en interne : "release". C’est au final un ensemble de procédures administratives et techniques qui vont amener la plateforme de la version en cours à une nouvelle version.

Pour cela, nous mettons au point un programme qui contient toutes les instructions nécessaires à la mise à jour, comme par exemple la nouvelle version du code source ou les requêtes SQL pour modifier les bases de données. Ce programme est tout simplement appelé un patch. Chez nous, c’est un assemblage de scripts Shell, de PHP et de SQL qui sera exécuté en une fois sur la plateforme.

Le choix du patch par rapport à d’autres techniques de diffusion de mises à jour s’est imposé à nous car, d’une part, le patch permet plus facilement de transmettre les mises à jour à des tiers qui utilise notre technologie sur leur infrastructure et, d’autre part, car il permet d’enrober la mise à jour de tout un ensemble de sécurités qui nous semblent critiques et qu'on détaillera ci-dessous.
 
Un prérequis de base, qui peut sembler évident, est de disposer AVANT la mise à jour d'une copie de sauvegarde des données à distance ainsi qu’une architecture de secours. C’est la sécurité ultime dans l’hypothèse où tout devait se passer affreusement ou horriblement mal.

Branle-bas de combat

Une fois le patch prêt et testé, il est copié en production puis exécuté pour démarrer la mise à jour. Le patch s’assure d'abord de la compatibilité de l’environnement dans lequel il est installé. C’est à dire qu'il vérifie les versions des logiciels installés, la cohérence des données et si la plateforme est dans une version supportée par le dit patch.

Le patch arrête ensuite tous les services qui doivent l’être pour leur mise à jour : apache, démons, mysql, serveur ftp. La mise à jour peut maintenant commencer en tout sérénité. Le patch crée une nouvelle copie complète du code source dans un dossier qui contient déjà toutes les versions antérieures. Un simple lien symbolique désigne le dossier qui contient la dernière version. Cela permet facilement de passer d’une version à une autre en modifiant un lien symbolique.
 
Un lien symbolique est une sorte d’alias qui peut pointer vers un fichier ou un dossier existant. Imaginons deux répertoires qui contiennent des versions différentes d’un même logiciel :
$ mkdir version1 version2 
$ ls 
version1 version2
On peux alors créer un lien symbolique "courant" qui pointe vers "version2" :
$ ln -s version2 courant
$ ls
courant version1 version2
En prenant l’habitude de toujours utiliser les sources dans "courant", on pourra faciliter la mise à jour du logiciel lors de la prochaine version :
$ mkdir version3
$ ln -sf version3 courant
Maintenant "courant" pointe vers "version3".

Les bases de données principales et celles de tous les sites sont ensuite scannées et mises à jour au besoin. Pour ça, nous avons disposé dans chaque base de données une table contenant un petit compteur indiquant dans quelle version elle est. Le patch peut alors déterminer quelle série de requêtes SQL il doit accomplir en comparant ce compteur avec sa version interne.
 
Le patch vérifie ensuite la cohérence des données avant de relancer tous les services qui avaient été arrêtés. Puis, ultime étape, il lance un ensemble de tests automatiques pour vérifier que tout à l’air de bien fonctionner. L’exécution du patch aura duré un peu moins de 10 minutes.
 
Une des dernières vérifications en date est un système de test de non-régression par carottage. Le principe est de collecter des échantillons de code HTML issus d’un panel représentatif de nos sites. Nous allons par exemple insister sur le catalogue produits ou le tunnel de commande des sites e-commerce, et sur le blog ou les pages de contenus des sites institutionnels. La comparaison des échantillons avant et après la mise à jour pourra garantir que les sites n’ont pas été altérés.

Après c’est au tour des humains avec leurs mains pleines de doigts de faire une petite recette manuelle du bon fonctionnement de tout ce qui a été modifié par la mise à jour avant de réouvrir l'accès à tout le monde.

10 ans de retours d'expérience

Notre système de release a évolué petit à petit en 10 ans pour être de plus en plus fiable. Il s’est construit empiriquement au contact de tout ce qui a mal fonctionné. Nous avons évidement anticipé le maximum de soucis que nous pouvions rencontrer, mais la réalité est toujours pleine de surprises ! Alors c’est parti pour un top 7 des enseignements que nous avons tiré de tout ça :

1. Le dev, c'est pas la prod

Le patch doit être testé sur un environnement le plus proche possible de la production. Même type de serveurs, mêmes systêmes d'exploitation, mêmes versions de tout ce qui a été installé dessus. Et dans l’idéal avec une copie des données de production, même partielle. Nous utilisons des machines virtuelles avec snapshot, ce qui nous permet de figer un environnement dans un état idéal puis de rejouer la mise à jour autant de fois que nous le souhaitons.

Dans la lise des pépins qui nous est arrivé, on peut citer la fois où l’inclusion d’un fichier fonctionnait sur les environnement de tests où le système de fichier n’était pas sensible à la casse, mais plantait en production où le système de fichier est sensible à la casse. Tout cela aurait pu être détecté avec un test de mise à jour sur un environnement ISO.

2. L’erreur est humaine

Le patch est un bout de code à poser et à exécuter tel quel. Le minimum d’opérations doit être effectué à la main car il est toujours possible de se tromper dans l’ordre des étapes à suivre ou de faire une faute de frappe/copier/coller dans une ligne de commande. Quel est le sysadmin qui n’a jamais fait de "rm -rf /" me kill -9 le premier shell.

Il y a 10 ans, l’arrêt des services était fait manuellement, ce qui était source d’erreurs. Maintenant c’est fait de façon automatique. C'est fiable et beaucoup plus rapide. On y a gagné également en confort, on sait que tout est arrêté dans les règles de l’art.

3. Chérie, ça va couper

Ne pas hésiter à faire une interruption de service pendant les mises à jour pour des raisons de simplicité et de fiabilité. Nous avons le luxe d’arrêter tous les services qui utilisent le code source, de purger les caches, puis de les redémarrer une fois le nouveau code en place. On exclut donc les possibilités d’avoir différents bouts de la plateforme qui exécutent des versions différentes du code en manipulant différentes versions des données. Et des bouts, il commence à y en avoir un paquet, entre les APIs, les sites, les consoles d’administration, sans compter les différents démons qui s’occupent des imports/exports, des envois d'emails, etc.

Pour assurer une mise à jour à chaud, il faudrait prévoir et tester le fonctionnement des différentes parties de la plateforme malgré des variations dans les versions de code source et des données. C’est beaucoup de temps, d’efforts et de complexité pour garantir un fonctionnement dans des conditions exceptionnelles qui ne durent en principe que le temps de la mise à jour.

Un dernier avantage est aussi de pouvoir dédier toute la puissance des serveurs à la mise à jour. Les bases de données sont par exemple soulagées de quasiment toute leur charge. Et malgré tout, c’est la mise à jour des quelques milliers de tables nécessaires qui reste l’opération la plus longue actuellement (dans les 5 minutes). Il en serait autrement à pleine charge.

Il faut toujours néanmoins penser aux utilisateurs et proposer un écran de courtoisie expliquant qu'une mise à jour est en cours. Une petite page statique "Mise à jour en cours" est la moindre des choses plutôt qu’un site qui ne réponds pas du tout.
 
Petit détail SEO, pendant nos périodes de maintenance, nous prennons soin de diffuser un code HTTP 503 pour signaler aux moteurs de recherche qu’une maintenance est en cours et qu’il faudra repasser un peu plus tard.

4. Ça passe ou ça casse c’est comme avant

C’est bien d’avoir un plan d’action quand tout se passe bien, mais c’est encore mieux d’en avoir un dans le cas où ça dérape. Le point le plus crucial est qu'un patch sache non seulement comment mettre à jour l'architecture mais aussi comment revenir en arrière en cas de soucis. Il doit pouvoir défaire de façon autonome tout ce qu’il a fait. C’est à dire qu’à la moindre erreur, à n’importe quelle étape, la plateforme doit revenir à son état d’origine.

Pour le code source, c’est facile car le code est archivé. Un simple changement de lien symbolique et tout est à nouveau en place. Pour les données, c’est un peu plus complexe. Hors de question de restaurer la sauvegarde, ça prendrait bien trop de temps. Le patch doit contenir le code permettant directement de faire les opérations inverses. Si un patch ajoute par exemple un champ dans une table Mysql, il doit savoir l’enlever aussi.

5. Les logs, c’est la vie

Le patch doit écrire dans un coin absolument tout ce qu’il fait. La moindre petite commande, et sa sortie, aussi insignifiante soit-elle, doit être loggée et horodatée. C’est très important pour identifier les problèmes, les corriger et améliorer le patch pour la prochaine fois.

Ça nous est arrivé d’analyser ces logs pour identifier les parties du patch les plus lentes et les optimiser. C’est comme ça que le temps d’exécution des patchs est passé de 45 minutes à moins de 10 actuellement.
 
Nous utilisons deux petites fonctions shell bien pratiques pour exécuter ET logger une commande en même temps :
function log {
echo "-- $(date) : $*" >> update.log
}
function xlog {
log "$*"
$* >> update.log
}
Par exemple la copie d’un fichier :
$ xlog cp fileA fileB

6. Notez tous les accros

A chaque release, notez tout ce qui s’est mal passé et trouvez une solution pour que ça ne puisse plus arriver la prochaine fois, quitte à rajouter des tests, des sécurités ou en automatisant mieux les taches. Dans le cas où ça ne concerne pas directement le patch, mettez à jour une checklist des points à vérifier avant la mise à jour.

Des fois, il s’agit juste de circonstances exceptionnelles. Il nous est arrivé d’avoir un problème de réseau au moment où nous testions une mise à jour, ce qui a coupé la connexion avec la machine virtuelle de test. Les sessions SSH se sont évidement coupées également en entrainant l’arrêt de l’exécution d'un patch en plein milieu. Depuis, le patch refuse de se lancer s’il n’est pas dans un screen.

7. Bien plus qu’un patch

Le patch n’est pas le seul élément d’une release. Nous préparons également un ensemble de documents pour cadrer l’intervention, à savoir :
  • un bulletin de révision qui contient une liste de toutes les améliorations, nouveautés ou correctifs de la mise à jour
  • la checklist des quelques étapes manuelles à faire
  • une fiche d’intervention qui précise qui touche à quoi, pour quelle raison et avec le détail de ce qui s’est bien/mal passé
  • une cahier de tests pour effectuer la recette de la mise à jour

TL;DR

Une relase est un processus rafiné par le temps et l'experience, qui nous permet d’aborder les mises à jour avec un état d’esprit apaisé et confiant : nous savons exactement quoi faire, que le tout a déjà été exécuté avec succès sur un environnement ISO prod, qu’une stratégie de retour en arrière est en place et que des diagnostiques automatiques vont nous aiguiller rapidement vers d’éventuels problèmes.

Mais on vous rassure, nous gardons quand même un petit frisson quand on est sur le point d’appuyer sur le bouton ;)

Derniers billets postés

Haut de page