Chaîne de livraison
Retirer la décision de livrer de la réunion. Des changements construits, testés et livrés de la même façon à chaque fois, avec un retour arrière ordinaire plutôt qu'un incident.
Compétences
Cloud et infrastructure
Ce sur quoi tout le reste tourne, de la chaîne de livraison jusqu'aux machines.
le problème métier
La plupart des équipes n'ont pas un problème de déploiement, mais de confiance.
Quand personne ne sait dire ce que contient une livraison ni comment revenir en arrière, la réponse rationnelle est de livrer rarement. Livrer rarement rend chaque livraison plus grosse, et plus grosse la rend plus dangereuse : l'argument revient à son point de départ.
En dessous se trouve l'infrastructure elle-même. Beaucoup d'organisations ne peuvent pas tout confier au cloud d'un tiers, pour des raisons de réglementation, de latence, de coût à grande échelle, ou par refus de remettre le cœur de l'activité à une société libre de changer ses tarifs.
Dans les deux cas le résultat est identique : ce dont tout dépend est compris par très peu de personnes et documenté par personne.
ce que nous apportons
- Build, tests et livraison automatisés, pour un seul chemin vers la production
- Contrôles de sécurité dans la chaîne plutôt que dans un rapport lu après coup
- Architecture cloud, et un avis honnête sur ce qui ne devrait pas y aller
- Installation, configuration et administration continue de serveurs
- Sauvegarde et restauration, vérifiées en restaurant réellement
missions types
Architecture et migration cloud
Décider ce qui tourne où, le déplacer, et être clair sur ce qu'il vaut mieux laisser en place.
Construction d'infrastructure
Alimentation, refroidissement, plan réseau, serveurs. Un travail ingrat qui décide si tout ce qui est au-dessus reste debout.
Reprise de l'existant
Hériter d'une infrastructure que personne n'a documentée, en commençant par un audit, car la première tâche est de découvrir ce qu'elle fait.
notre façon de procéder
Nous automatisons d'abord l'étape manuelle la plus dangereuse.
Le risque baisse avant la fin du projet, ce qui compte parce qu'un travail d'infrastructure obtient rarement le luxe d'un trimestre calme.
Nous écrivons ce que nous avons fait. Une infrastructure que seul son installateur comprend est un point de défaillance unique monté en rack, et la défaillance arrive le jour où cette personne est absente.
architecture de référence
Comment nous disposons un environnement
Un modèle de référence, et non le système d'un client. Chaque couche répond à une question différente sur ce qui se passe quand quelque chose s'arrête.
- 01
Livraison
Comment un changement atteint la production, comment il est testé en chemin, et comment il en ressort.
- 02
Exécution
Où l'application tourne réellement, et ce qu'il advient du trafic quand une partie tombe.
- 03
Réseau
Ce qui peut joindre quoi. Segmenté plutôt que plat, car un réseau plat est à une erreur de devenir total.
- 04
Stockage et reprise
Où vit l'état, comment il est sauvegardé, et la dernière fois que quelqu'un en a restauré avec succès.
- 05
Accès
Accordés par rôle et revus, plutôt qu'accumulés par quiconque en a eu besoin un jour.
technologies
- Docker
- GitHub Actions
- Cloudflare
- PostgreSQL
questions
- Faut-il tout migrer vers le cloud ?
- Généralement pas tout. La réglementation, la latence, le coût à grande échelle et le contrôle sont autant de raisons légitimes de posséder des machines, et un prestataire qui recommande la migration complète dans tous les cas ne lit pas votre situation.
- En combien de temps cela se rentabilise-t-il ?
- Le travail sur la chaîne se voit généralement en quelques semaines, car le coût supprimé est celui des heures autour de chaque livraison et des incidents causés par des déploiements rares et volumineux. Une construction d'infrastructure a un horizon plus long, et ce sont les approvisionnements qui en fixent l'essentiel.
- Le DevSecOps, concrètement ?
- Des contrôles de sécurité qui tournent dans la chaîne de livraison plutôt qu'en revue après coup. Concrètement, un changement porteur d'une vulnérabilité connue n'atteint pas la production, au lieu d'être découvert dans un rapport trimestriel.
- Restez-vous ensuite ?
- Si vous le souhaitez. L'objectif est que vous n'en ayez pas besoin, et c'est pourquoi la reprise comprend la documentation et la répétition plutôt que seulement les accès.
va souvent avec
Apportez-nous le problème.
Nous commençons par une session de travail sur votre activité réelle, pas par un argumentaire générique. Vous en ressortez en sachant ce qui se passe, ce qu'il faut corriger en premier, et à quoi ressemble la suite.