Paul Biggar, co-fondateur de CircleCI a présenté "les différentes manières de déployer en continu" à RubyConf 2013 en avril de cette année. La fréquence à laquelle les déploiements s'effectuent détermine le terme de "continu" et influence directement le cadre du problème du déploiement. La présentation rassemble des informations sur les solutions issues de la propre base client de CircleCI, Facebook, IMVU, Etsy, Heroku et Google. Ils se sont aperçus que chaque société aborde le déploiement de manière légèrement différente et qu'il n'existe pas une unique solution pour déployer en continu.
Paul a présenté les détails de comment les solutions de déploiement vont avoir des processus incluant du code, des modifications dans les bases de données, des unités de déploiement, de la vitesse de déploiement, de tests et du monitoring. Il a dit que les variables affectant le développement de ces solutions de déploiement incluent la vitesse des nouvelles fonctionnalités, la complexité du code, l'architecture logicielle, la conception logicielle, le nombre d'ingénieurs et l'état du monitoring.
Paul a expliqué que la solution la plus répandue pour gérer l'état transititoire pendant le déploiement en production, la "Course" consistait à déployer du code qui supportait à la fois l'ancienne et la nouvelle fonctionnalité. Cela nécessite des ingénieurs capables de programmer une fonctionnalité de telle sorte que le nouveau code puisse s'exécuter en toute sécurité juste à côté de l'ancien code. Les bases de données présentent le défi supplémentaire du stockage de l'état. A première vue, il semble que la mise à jour préalable de l'application capable de supporter les deux versions de la base de données soit suffisante ; avant de changer la version de la base de données. Toutefois, dans certains cas, les modifications des bases de données SQL provoquent tant de verrous que le seul choix raisonnable soit de créer une nouvelle table de base de données pour chaque version et de migrer ensuite les données "hors bande". L'application sera alors codée pour vérifier la nouvelle table et de se replier sur l'ancienne table si la donnée n'est pas disponible. Le NoSQL est en partie devenu populaire car il peut éviter le scénario des verrous.
La présentation aborde des aspects supplémentaires du déploiement, incluant les unités de déploiement, la vitesse, la validation via les tests et la surveillance via le monitoring. Bien que ces points ne soient pas des exigences fonctionnelles du déploiement, le niveau de ces capacités détermine le degré de déploiement continu.