Dans cet article :<\/strong><\/p>\n Que vous soyez DevOps, SRE (Site Reliability Engineering) ou ITOps (une combinaison des deux), la continuit\u00e9 des services est une responsabilit\u00e9 partag\u00e9e. Pour que tout continue \u00e0 fonctionner dans votre entreprise et que vos SLA et SLO soient respect\u00e9s, vous devez garantir la fiabilit\u00e9 et la r\u00e9silience de plusieurs applications – vos syst\u00e8mes d’entreprise, les donn\u00e9es transactionnelles et de configuration, les monolithes et les microservices, probablement par le biais d’un mix entre plateformes et technologies.<\/p>\n Et si le d\u00e9ploiement des applications a toujours \u00e9t\u00e9 la phase la plus critique du cycle de vie des logiciels, DevOps et le passage au cloud ne font qu’accro\u00eetre la complexit\u00e9 du processus de d\u00e9ploiement. Un transfert d\u00e9fectueux vers un environnement SaaS peut avoir un impact simultan\u00e9 sur tous les utilisateurs de ce service – et avec un taux \u00e9lev\u00e9 de changement d’application, la stabilit\u00e9 de votre syst\u00e8me est constamment \u00e0 risque.<\/p>\n<\/div> Dans les environnements hybrides d’aujourd’hui, l’automatisation du CI\/CD n’est qu’une partie de la r\u00e9ponse. Il est plus important de garantir la r\u00e9silience de vos applications que d’\u00e9chouer moins souvent. Les contraintes de temps signifient que le “report” n’est pas toujours une option, et les d\u00e9ploiements fr\u00e9quents n\u00e9cessitent un m\u00e9canisme automatis\u00e9 de retour en arri\u00e8re (rollback) qui remplace n-1 de vos logiciels et donn\u00e9es dans tous les syst\u00e8mes cibles.<\/p>\n Ajoutons \u00e0 cela que la plupart des mises en \u0153uvre DevOps sont personnalis\u00e9es avec des outils sp\u00e9cifiques et adapt\u00e9es \u00e0 une seule t\u00e2che – propre \u00e0 une seule \u00e9quipe, et \u00e0 une seule application. D\u00e9sormais, les outils de gestion des versions doivent fonctionner par “macro-release”, en construisant automatiquement un pipeline pour chaque CI\/CD – en fonction des donn\u00e9es (et non d’une \u00e9quipe sp\u00e9cifique).<\/p>\n<\/div> Il va sans dire que la s\u00e9curit\u00e9 est une pr\u00e9occupation primordiale et qu’il faut y pr\u00eater attention tout au long du cycle DevSecOps. Alors que les outils SAST (Static Application Security Testing) analysent le code source statique pour \u00ab shift left \u00bb la s\u00e9curit\u00e9, toute vuln\u00e9rabilit\u00e9 open source doit \u00eatre d\u00e9tect\u00e9e dans les fichiers binaires avant toute importation dans le r\u00e9f\u00e9rentiel d’artefacts.<\/p>\n Les outils de Release Management doivent donc \u00eatre compl\u00e9t\u00e9s par des Policy engines pour avoir acc\u00e8s aux renseignements les plus r\u00e9cents sur les composants open source.<\/p>\n<\/div> En r\u00e9ponse \u00e0 tous ces d\u00e9fis, DROPS est une solution d’Orchestration des d\u00e9ploiements d’Applications (ARO) simple \u00e0 utiliser – une seule console pour s\u00e9curiser, d\u00e9ployer, suivre et r\u00e9tablir les applications dans tout votre \u00e9cosyst\u00e8me. DROPS g\u00e8re les logiciels, les donn\u00e9es, les mises \u00e0 jour de la structure des bases de donn\u00e9es et les donn\u00e9es ou param\u00e8tres de configuration. Un seul outil pour d\u00e9ployer en toute s\u00e9curit\u00e9 sur les syst\u00e8mes open, IBM i ou mainframe System z, les conteneurs Docker, les clusters Kubernetes, et toutes les plateformes cloud comme AWS, Azure et GCP.<\/p>\n DROPS travaille au niveau des applications et des groupes d’applications, en s\u00e9quen\u00e7ant les d\u00e9ploiements individuels dans l’ordre des d\u00e9pendances pour garantir la coh\u00e9rence et l’int\u00e9grit\u00e9 du syst\u00e8me global.<\/p>\n<\/div>\n
Pourquoi CI\/CD n’est pas suffisant ?<\/h2><\/div>
La s\u00e9curit\u00e9 est l’affaire de tous<\/h2><\/div>
DROPS Orchestration des mises en production d’applications \u2013 tout en un<\/h2><\/div>