DevSecOps et coordination des versions – Blogs insuffisants

Le défi de la coordination des publications

Journée de publication. Il y a peu de mots plus terrifiants dans le lexique de l'équipe de développement. C'est le moment de vérité; nos efforts seront-ils vains ou aurons-nous une autre sortie de production? Et tant de choses peuvent aller mal; Avons-nous manqué des exigences critiques, avons-nous échoué à tout tester de manière efficace, y a-t-il d'autres applications qui subiront un impact négatif ou qui pourraient être publiées en même temps? Et qu'en est-il de notre conformité en matière de sécurité, avons-nous correctement évalué notre application pour nous assurer que non seulement l'application est correctement sécurisée, mais également l'environnement cible? Compte tenu de toutes ces questions et de nombreuses autres questions à résoudre le jour de la publication ou peu avant, il ne faut pas s'étonner que les publications soient retardées ou, pire encore, obligées de revenir à une version précédente.

Figure 1. Journée de lancement de la navette – photo de NASA.gov

Nous pouvons donc identifier bon nombre des problèmes rencontrés par les coordinateurs de publication, mais comment utilisons-nous réellement ces informations pour améliorer la qualité et la rapidité de nos publications? Le principal facteur de blocage est souvent l'identification tardive de «l'état de préparation à la libération». Cela représente la certitude qu'un candidat système donné a été correctement défini, construit, testé et préparé pour être libéré dans la «nature».

Beaucoup a été écrit sur l'utilisation de DevSecOps pour accélérer la mise en production de fonctionnalités via un développement agile, une intégration continue et un déploiement continu. Mais comment l’automatisation de DevSecOps améliore-t-elle la qualité de nos versions et, plus important encore, comment réduit-elle le temps nécessaire pour «approuver» une version donnée? L'automatisation à elle seule est probablement insuffisante sans une pratique correspondante et complémentaire de coordination de la publication. Après tout, la livraison plus rapide d'un produit endommagé ne devrait pas rendre l'utilisateur final plus heureux. De plus, si le processus impose une série de «portes» différées nécessitant plusieurs approbations de la part de hauts dirigeants, censées accroître la confiance d'un produit de qualité, tout gain de vitesse sera éliminé de l'automatisation de la construction et du déploiement de CI / CD.

Nous sommes donc confrontés à la situation dans laquelle nous souhaiterions réduire le travail manuel associé aux déploiements effectués par l’automatisation de DevSecOps, mais nous voulons avoir la certitude que le produit commercialisé a été évalué pour une utilisation en production.

The Presumptive Release

Dans «The Goal», Eliyahu Goldratt et Jeff Cox ont présenté l’idée que, dans un processus de fabrication, toutes les étapes qui ne conduisent pas à «l’objectif» du processus devraient être éliminées. Cette approche souligne l’importance du résultat final sur le processus lui-même et est au cœur de l’idée de Lean Manufacturing . Il représente également le cœur du développement agile où la livraison du produit est retardée, par exemple lors de la création de documents. Afin de piloter la version de production d'un système logiciel donné, je vais introduire le terme «publication présumée» où chaque version candidate est considérée comme une cible pour la production! Considérez la conséquence de cette affirmation – si nous voulons Considérez chaque candidat annoncé par l'équipe de livraison comme une version de production potentielle. Nous devons ensuite déplacer notre évaluation de ce candidat le plus loin possible dans le processus de développement. Cela signifie que nous devons détecter et résoudre les problèmes liés aux versions tôt dans l'évaluation (telles que les violations des règles de sécurité). En outre, cela signifie également que nous éliminerons les étapes de processus non exécutées en habilitant les membres clés de l’équipe à assumer la responsabilité d’affirmer que a terminé les étapes critiques de préparation à la publication. Enfin, nous devons sans ambiguïté définir quels critères doivent être remplis avant une telle affirmation.

Coordination de la publication – États de disponibilité clé

Quel que soit le processus suivi pour créer une version de candidat au développement donnée (par exemple: agile, cascade, scrumfall, wagile, etc.), il existe un ensemble d’états définis de préparation à la libération qui doivent être déterminés, vérifiés et affirmés. De plus, il y a des rôles clés associés à l'encadrement du candidat tout au long du processus de libération, qui sont les seuls habilités à arrêter la libération. Par définition, une approche de publication présomptive suppose que chaque candidat annoncé est non seulement prêt pour la production, il sera publié à moins que l'un des rôles de coordination de la publication habilitée ne décide de mettre fin à ses fonctions.

Figure 2. États de préparation à la publication et responsabilités DevSecOps

Il existe quatre états de disponibilité clés et quatre rôles de publication clés, comme l'illustre la figure 2. Les états de préparation à la publication sont Produit, Organisation, Sécurité. et opération. L'état de préparation du produit indique que les exigences du système de libération des candidats ont été minutieusement évaluées et testées. Ceci est généralement effectué en premier par l'équipe de développement à travers une série de tests unitaires manuels et automatisés. Une fois que le système est considéré comme suffisamment stable, il est promu dans un environnement de test pour évaluation par l'équipe d'assurance qualité. Cette équipe vérifie ensuite la conformité aux exigences de fonctionnalité, de performances et de sécurité du système. Enfin, lorsque l'équipe de développement annonce la publication du candidat, celle-ci passe dans l'environnement d'acceptation des utilisateurs pour l'évaluation de la fonctionnalité du produit final. L’affirmation de «l'état de préparation du produit» indique que toutes ces étapes sont terminées et que tous les problèmes en suspens sont notés mais annulés pour le candidat actuel. La disponibilité organisationnelle indique que toutes les communications nécessaires ont été préparées et distribuées, telles que les notes de mise à jour, les livres de support, les guides de dépannage et la formation des équipes de support. Disponibilité opérationnelle indique une mise à jour du plan de mise à jour, des cahiers d'exécution et d'autres artefacts de support requis pour le soutien de la production en cours. Enfin, l'état Security Readiness indique que le produit a été évalué pour les vulnérabilités, les exploitations potentielles et la vérification par rapport à toutes les politiques de sécurité définies.

Coordination de la publication – Rôles clés

Les quatre rôles clés en matière de publication sont: Chef de produit, architecte de sécurité, coordinateur des opérations et coordinateur des versions. Ces rôles, et uniquement ces rôles, sont habilités à affirmer que leur état de préparation à la libération est complet. Si l'un de ces rôles, et uniquement ces rôles, est incapable de confirmer qu'un aspect particulier d'un ou de plusieurs états de préparation n'est pas complet, ils peuvent arrêter la publication. Aucune autre approbation n'est requise. Si une erreur est détectée ultérieurement dans le système de production, un audit de trace en arrière indiquera le lieu de l'échec dans le processus de validation et autorisera la correction. Comme le montre la figure 2, le propriétaire du produit est responsable en dernier ressort de l'état de préparation du produit, le coordinateur des opérations est propriétaire de l'état de préparation des opérations et l'architecte de sécurité est responsable de l'état de préparation de la sécurité. Le coordinateur des versions, qui est directement responsable de l'état de préparation de l'organisation, est également responsable de la supervision de tous ces rôles. Le coordinateur des versions s'assure que tous les différents états de préparation sont suivis et affirmés. De plus, ce rôle est propriétaire et exécute la réunion de coordination des versions qui planifie les ressources pour les versions à venir, vérifie qu'aucune collision de produit (par exemple, violation de dépendance) n'est créée et que les environnements cibles sont préparés pour la version de production.

profondément chacun de ces rôles et états de préparation à la publication dans les articles de blog suivants. Avec l’automatisation de DevSecOps des activités de construction, de package, de version, de déploiement et de test, l’approche de la «publication présomptive» pour la gestion des versions incite à la responsabilité, attribue un droit de propriété clair et réduit les coûts de gestion associés au processus type de publication en production. ! function (f, b, e, v, n, t, s) {if (f.fbq) retourne; n = f.fbq = fonction () {n.callMethod?
n.callMethod.apply (n, arguments): n.queue.push (arguments)}; if (! f._fbq) f._fbq = n;
n.push = n; n.loaded =! 0; n.version = '2.0'; n.queue = []; t = b.createElement (e); t.async =! 0;
t.src = v; s = b.getElementsByTagName (e) [0]; s.parentNode.insertBefore (t, s)} (fenêtre,
document, 'script', '// connect.facebook.net/en_US/fbevents.js');

fbq ('init', '911436665572720');
fbq ('track', "PageView");

Source link