Nous réalisons un projet cloud pour le développement - une plate-forme qui peut simplifier la vie des développeurs, développeurs, testeurs, chefs d'équipe et autres spécialistes impliqués dans le processus de développement autant que possible. Ce produit n'est pas pour l'instant et pas pour demain, et le besoin est en train de se former.
L'idée principale est que vous pouvez déployer le pipeline avec des outils préconfigurés, mais en même temps avec la possibilité de faire un certain nombre de paramètres, tout ce que vous avez à faire est de déployer le code.
D'où vient une telle perversion? Nous constatons une tendance claire selon laquelle la vitesse de déploiement de nouveaux projets affecte désormais le marché. Le commerce dépend de la rapidité avec laquelle les versions sont livrées. De la rapidité avec laquelle les bugs seront corrigés, de la rapidité avec laquelle de nouvelles niches seront engagées. Début 2018, la société mondiale «451 Research» a mené une enquête sur les technologies qui seront prioritaires pour le développement. Le top dix comprend les technologies de création et de gestion de conteneurs, ainsi que l'architecture des applications sans serveur et les microservices, dépassant même un sujet aussi hype que la blockchain.
Et maintenant, nous avons quelques questions pour vous.
Graphique de l'enquête:
Est-ce nécessaire?
L'utilisation de conteneurs dans le développement d'un nouveau produit a ses avantages et ses inconvénients. L'utilisation ou non de cette technologie doit être décidée en fonction des tâches définies. Pour certaines tâches, l'utilisation de conteneurs ne peut pas être supprimée et pour certains, elle est simplement superflue. Par exemple, pour les sites à faible trafic, une architecture simple de deux serveurs suffira amplement. Mais si une croissance significative du développement est prévue, ainsi qu'une énorme augmentation du nombre de visiteurs dans un court laps de temps, alors dans ce cas, il convient de considérer l'infrastructure utilisant des conteneurs.
L'utilisation de conteneurs présente plusieurs avantages:
- Chaque application s'exécute de manière isolée dans son propre conteneur, ce qui minimise les problèmes liés à la configuration.
- La sécurité des applications est également obtenue en isolant chaque conteneur.
- Étant donné que les conteneurs utilisent le noyau du système d'exploitation, le système d'exploitation invité n'est désormais plus nécessaire, ce qui permet de libérer une grande quantité de ressources.
- De plus, en raison de l'utilisation du noyau du système d'exploitation et du fait que vous n'avez pas besoin de compter sur l'hyperviseur, les conteneurs nécessitent beaucoup moins de ressources que les autres piles.
- Encore une fois, du fait que les conteneurs ne nécessitent pas de système d'exploitation invité, ils sont faciles à migrer d'un serveur à un autre.
- Du fait que chaque application s'exécute dans un conteneur isolé, il est facile de transférer de la machine locale vers le cloud;
- Il est très «bon marché» de démarrer et d'arrêter le conteneur en raison de l'utilisation du noyau du système d'exploitation.
En relation avec tout ce qui précède, nous pensons que la technologie de conteneurisation est actuellement la pile la plus rapide, la plus économe en ressources et la plus sécurisée. En raison des avantages des conteneurs, vous pouvez avoir le même environnement à la fois sur la machine locale et en production, ce qui facilite le processus d'intégration continue et de livraison continue.
Les avantages des conteneurs sont si convaincants qu'ils seront certainement utilisés longtemps.
Qu'est-ce que le cloud a à voir avec le développement?
Dans le monde idéal du développeur, tout code de validation devrait être déployé en production en un seul clic, comme par magie.
Nous l'avons fait de cette façon: il y a un Gitlabchik avec des tâches et une source. Lorsque vous devez collecter quelque chose - GitLab Runner. Nous travaillons sur Git Flow, toutes les fonctionnalités sur des branches distinctes. Lorsqu'une branche entre dans le référentiel, les tests sur ce code sont lancés dans GitLab. Si les tests réussissent, le développeur de ce fil peut faire une demande de fusion, en fait une demande de révision de code. Après l'examen, la branche est acceptée, fusionnée dans la branche dev, les tests la repassent. Lors du déploiement, GitLab Runner collecte le conteneur Docker et le transfère vers le serveur de transfert, où il peut être cliqué et réjoui. Et voici le premier gag - nous examinons le code avec nos mains pour vérifier la conformité avec le fonctionnel et c'est la première chose que nous corrigeons. Après cela, nous injectons le code dans la branche de publication. Et pour elle, nous déployons une version préproductive distincte de notre solution, que nos clients commerciaux regardent. Une fois que la version est préinstallée sur la pré-prod, nous la roulons en production et elle roule jusqu'aux nœuds du produit. Il existe des notes de version et des rapports de bogues générés automatiquement. La vitesse d'assemblage était de plus de 30 minutes, elle est maintenant d'un ordre de grandeur en moins. Nous avons sélectionné un ensemble d'outils pour nous-mêmes et réfléchissons maintenant à la façon de créer le même SaaS prêt à l'emploi.
Pour nous, le processus de sortie typique pour la sortie est le suivant:
- Fixer des objectifs pour l'implémentation de nouvelles fonctionnalités
- Localisation de code
- Apporter des modifications en fonction des tâches. Écriture de tests automatisés avant la construction.
- Vérification du code, manuel et auto-test
- Fusion de code dans une branche de développement
- Créer une branche de développement
- Déployer l'infrastructure de test
- Déployer la version sur l'infrastructure de test
- Exécution de tests, fonctionnels, intégration, etc.
- En cas de bugs, terminez-les immédiatement dans la branche dev
- Migration d'une branche de développement vers une branche principale
Voici un schéma avec les détails de notre processus:
En fait, la première question - s'il vous plaît dites-nous où vous ratissez quel type de râteau était et comment universel ou non ce régime est. Si vous utilisez un flux de travail très différent de celui-ci, ajoutez quelques mots, pourquoi donc, s'il vous plaît.
Quel type de produit prévoyons-nous?
Nous avons décidé de ne pas copier Amazon à cet égard, mais de mener notre développement en tenant compte des spécificités du marché. Faites immédiatement une réserve que tous les calculs sont notre opinion subjective basée sur notre analyse. Nous sommes ouverts à un dialogue constructif et sommes prêts à changer la feuille de route du produit.
Lors de l'analyse du pipeline existant d'Amazon, nous sommes arrivés à la conclusion qu'il possédait d'énormes capacités, mais l'accent était mis sur de très grandes équipes d'entreprise. Il nous a semblé que pour déployer un microservice dans Docker, il était excessivement long, plus que si, par exemple, il était déployé dans Kubernetes, car il y a un endroit pour configurer les configurations internes, définir les accords internes, etc. et tout cela doit être compris depuis longtemps.
D'autre part, il y a, par exemple, Heroku, où vous pouvez déployer en un clic. Mais en raison du fait que les projets, en règle générale, sont assez ramifiés, avec des microservices tiers, à un moment donné, il devient nécessaire de déployer des images de docker personnalisées avec des services DBaaS et tout cela ne rentre pas dans Herocku car c'est soit cher soit inconfortable.
Nous voulons trouver une autre option. Le juste milieu. Selon le type de projet et les tâches, vous fournir un ensemble d'outils déjà préconfigurés qui sont déjà intégrés dans un seul pipeline, tout en laissant à la fois la possibilité d'un changement profond des paramètres et la possibilité de remplacer les outils eux-mêmes.
Alors qu'est-ce que ce sera?
Écosystème, qui comprend un portail et un ensemble d'outils et de services pour minimiser l'interaction des développeurs avec le niveau de l'infrastructure. Vous définissez des paramètres environnementaux qui ne sont pas liés à l'environnement physique:
- Environnement de développement (système de gestion de la configuration, système de définition des tâches, référentiel de stockage du code et des artefacts, traqueur de tâches)
- CI - Intégration continue (assemblage, infrastructure et orchestration)
- QA - Assurance qualité (tests, surveillance et journalisation)
- Staging - Environnement d'intégration / Boucle de pré-publication
- Production - Circuit productif
En choisissant des outils, nous nous sommes concentrés sur les meilleures pratiques du marché.
Nous allons construire l'infrastructure avec Stage et Prod à l'aide de Docker et Kubernetes avec époussetage des fonctionnalités parallèles.
Cela se fera de manière itérative - à la première étape, un service est prévu qui vous permettra de prendre le fichier Docker du projet, puis de collecter le conteneur requis et de le disposer dans Kubernetes.
Nous prévoyons également d'accorder une attention particulière au service de suivi du processus de développement et de livraison continue. Qu'entendons-nous par ce service? C'est l'occasion de créer un modèle de KPI hiérarchique avec des indicateurs tels que le% de couverture par les tests unitaires, le temps moyen pour éliminer un incident ou un défaut, le temps moyen entre la validation et la livraison, etc.
La collecte des données sources de différents systèmes - tests des systèmes de gestion, gestion des tâches, composants CI / CD, outils de surveillance infra, etc.
Et le plus important est de montrer sous une forme adéquate disponible pour une analyse rapide - des tableaux de bord avec possibilité de drilldown, une analyse comparative des indicateurs.
Que voulons-nous faire
En fait, j'aimerais vraiment avoir de vos nouvelles à propos de tout cela et de nos plans pour les étapes. Maintenant, ils sont:
- Infrastructure et orchestration - Docker et Kubernetes
- Définition des tâches, stockage du code et des artefacts, traqueur de tâches - Gitlab, Redmine, S3
- Production et développement - Chef / Ansible
- Assemblage - Jenkins
- Test - Sélénium, LoadRunner
- Surveillance et journalisation - Prometheus & ELK
- Soit dit en passant, comment voyez-vous si au sein de la plate-forme il y aura un choix - si vous vouliez, choisissez Jenkins, ne vouliez pas - GitLab Runner?
- Ou peu importe ce qu'il y a à l'intérieur, l'essentiel est que tout soit correctement construit, testé et déployé?
Comment peut-on aider?
Le produit sera développé pour les développeurs nationaux. Si vous nous dites maintenant comment procéder, il est probable qu'il sera inclus dans la version.
Veuillez me dire quelles piles vous utilisez actuellement. Vous pouvez - dans les commentaires ou par email à team@ts-cloud.ru.
UPD: pour plus de commodité, nous avons fait un court questionnaire sous forme Google -
ici .
De plus, nous vous tiendrons au courant du développement - et à un moment donné, nous donnerons aux participants assistants un accès à la version bêta (en fait, un accès gratuit à de bonnes ressources informatiques du cloud en échange de commentaires).