Le développement d’interfaces efficaces dans l’ingénierie de plateforme implique la transition des processus personnalisés et manuels vers des solutions standardisées et cohérentes qui simplifient l’approvisionnement et les demandes de service. Cet article explore les étapes du développement d’interface, en mettant l’accent sur la configuration des environnements de développement et le diagnostic du comportement de l’application.
Processus personnalisés
Une collection de processus variés existe pour approvisionner différentes fonctionnalités et services, mais la cohérence de l’interface n’est pas prise en compte. Les processus personnalisés répondent aux besoins immédiats des individus ou des équipes et dépendent d’une intervention manuelle même si le fournisseur utilise des scripts d’implémentation automatisés.
La connaissance de la façon de demander ces solutions est partagée d’une personne à l’autre. Le processus de demande d’un service n’a pas de normalisation et de cohérence. L’approvisionnement et l’utilisation d’un service de plateforme nécessitent probablement une prise en charge approfondie du fournisseur de fonctionnalités.
L’absence de conditions et de normes centrales rend ce niveau approprié lorsque l’entreprise n’a pas encore identifié et documenté les attentes. Il peut être efficace pour les équipes des entreprises en phase de démarrage ou des initiatives de plateforme. Dans ces environnements, les équipes ont la liberté d’évoluer des processus et des capacités en fonction de leurs besoins, ce qui leur permet de fournir plus rapidement et de payer le prix de la normalisation uniquement si nécessaire plus tard.
Configurer un environnement de développement : les ingénieurs individuels rassemblent les étapes nécessaires à la configuration d’un environnement en demandant aux collègues, en recherchant de la documentation et en suivant leurs propres pratiques connues.
Diagnostiquer le comportement de l’application : les ingénieurs choisissent leurs propres outils et processus pour diagnostiquer le comportement. Ils sont chargés de prendre des mesures pour accéder à l’application et aux fichiers de log.
Normes locales
Les ingénieurs et les équipes d’ingénierie définissent de manière proactive des normes pour différentes fonctionnalités et services afin d’augmenter la quantité de partage des connaissances qui peuvent se produire au sein de l’organisation. Les communautés d’appui informelles s’appuient sur ces normes, mais elles dépendent des ressources et de l’engagement des individus et des équipes individuelles.
Configurer l’environnement de développement : les équipes individuelles définissent leurs propres outils et processus et tentent de s’assurer que les ingénieurs au sein des équipes respectent ces processus. Cela peut se faire par le biais de la documentation ou de conteneurs, mais le choix de la manière de documenter les outils et processus est piloté par l’équipe.
Diagnostiquer le comportement de l’application : les équipes individuelles définissent leurs propres pratiques et processus pour diagnostiquer le comportement. Teams s’appuie sur l’équipe DevOps/IT pour accéder aux ressources déployées.
Des interfaces cohérentes et standard pour l’approvisionnement et l’observation de plateformes et de fonctionnalités existent et répondent aux besoins généraux. Les utilisateurs sont en mesure d’identifier les fonctionnalités disponibles et sont activés pour demander des fonctionnalités dont ils ont besoin.
Les routes pavées ou les chemins dorés, sous la forme de documentation et de modèles, sont fournis. Ces ressources définissent comment approvisionner et gérer des fonctionnalités classiques à l’aide de modèles conformes et testés. Bien que certains utilisateurs puissent utiliser ces solutions par eux-mêmes, les solutions nécessitent souvent une expertise approfondie du domaine et, par conséquent, le support des mainteneurs est toujours vital.
Gestion importante requise par l’équipe centrale pour gérer les modèles/la documentation, en particulier en réponse aux besoins changeants des équipes.
Configurer un environnement de développement : il existe un investissement dans un chemin commun avec la documentation ou les modèles définissant les outils et processus requis dans l’organisation. Les équipes peuvent dériver des normes à mesure qu’elles modifient des modèles, mais ne se fusionnent pas dans une équipe centralisée.
Diagnostiquer le comportement de l’application : pratique standard définie pour l’accès et le diagnostic des ressources déployées.
Solutions en libre-service
Les solutions sont proposées d’une manière qui offre une autonomie aux utilisateurs et nécessite peu de support des mainteneurs. L’organisation encourage et permet aux solutions de fournir des interfaces cohérentes qui permettent la découverte et la portabilité de l’expérience utilisateur d’une fonctionnalité à une autre. Bien que libre-service, les solutions nécessitent une prise de conscience et une implémentation d’équipe. Afin d’améliorer cette expérience, il peut y avoir un langage interne guidé et simplifié qui permet aux utilisateurs d’adopter et d’intégrer des fonctionnalités de plateforme plus rapidement. Cela génère une collection cohérente de fonctionnalités centrées sur l’utilisateur, libre-service et cohérente.
Configurer un environnement de développement : les équipes d’ingénierie dépendent de la plateforme pour configurer des environnements de développement. Affordance existe pour découvrir les ressources disponibles. Les équipes d’ingénierie adoptent la plateforme exclusivement pour toutes les interactions. La plateforme facilite le partage des connaissances par le biais de la découverte et de la modification de modèles nouveaux et existants, augmentant continuellement la valeur offerte par la plateforme.
Diagnostiquer le comportement de l’application : les outils et services permettant d’observer les ressources/fonctionnalités sont fournis via la plateforme à la demande. La plateforme offre la fonctionnalité pour diagnostiquer et observer des ressources et des capacités.
Services intégrés
Les fonctionnalités de plateforme sont intégrées de manière transparente aux outils et processus que les équipes utilisent déjà pour effectuer leur travail. Certaines fonctionnalités sont configurées automatiquement, telles que l’observabilité ou la gestion des identités pour un service déployé. Lorsque les utilisateurs atteignent les bords des services fournis, il est possible de passer des solutions automatisées et de personnaliser leurs besoins sans quitter les offres internes, car les fonctionnalités de la plateforme sont considérées comme des blocs de construction. Ces blocs de construction sont utilisés pour créer des compositions transparentes et automatiques pour répondre aux cas d’usage de niveau supérieur tout en activant une personnalisation plus approfondie si nécessaire.
Les équipes de plateforme interne peuvent déterminer quelles fonctionnalités fonctionnent bien pour l’organisation et peuvent utiliser ces connaissances pour déterminer les domaines dans lesquels investir pour améliorer davantage la plateforme.
Les fonctionnalités peuvent être étendues et empaquetées de plusieurs façons, offrant une flexibilité maximale pour approvisionner, gérer et observer les ressources et les fonctionnalités.
Configurer l’environnement de développement : les fonctionnalités de plateforme sont intégrées aux outils et processus que les équipes utilisent déjà pour effectuer leur travail. Peut être utilisé via l’interface CLI, l’IDE ou d’autres environnements.
Diagnostiquer le comportement de l’application : la plateforme configure automatiquement les fonctionnalités d’observabilité pour chaque application déployée. La plateforme fournit des affordances pour interagir avec les données de diagnostic et l’application déployée.