Recommandations pour maintenir un serveur de compilation à jour

En tant qu’homme qui bascule fréquemment entre l’AQ, la génération et les opérations, je continue à me demander ce qu’il faut faire à propos des mises à jour du système d’exploitation sur le serveur de génération. La dichotomie est la même sur Windows, Linux, MacOS ou tout autre système d’exploitation pouvant se mettre à jour via Internet:

L’équipe QA souhaite conserver le serveur de génération exactement comme au début du cycle de lancement du produit, car l’installation des mises à jour risque de déstabiliser le serveur et de ne pas créer des versions successives sur la même base.
L’équipe Ops souhaite que le logiciel soit déployé sur un système avec tous les derniers correctifs de sécurité; Cela peut signifier que le logiciel n’est pas déployé exactement sur la même version que le système d’exploitation sur lequel il a été construit.

J’atténue généralement ce problème en prenant en charge les versions candidates et en les installant sur un serveur de test qui a un o / s entièrement à jour, en répétant les tests automatisés exécutés sur le serveur de génération et en effectuant des tests supplémentaires au niveau du système. tout semble bon avant le déploiement. Cependant, cela me semble inefficace; Quelqu’un at-il une meilleure façon?

Personnellement, je ne pense pas que vous avez beaucoup de problème ici – il suffit d’appliquer les dernières mises à jour sur le serveur de génération. Les principales raisons pour lesquelles je dis cela sont:

il est hautement improbable que votre code ou l’une des dépendances du serveur de génération soit si étroitement lié à la version du système d’exploitation que l’installation de mises à jour régulières affecte tout, et encore moins le casse. Il peut y avoir des différences mineures entre les messages de la fenêtre, etc. entre les versions de Windows, mais celles-ci sont rares et sont généralement assez bien documentées sur Internet. Si vous utilisez des stacks de technologies gérées telles que WPF / Silverlight ou ASP.Net et même principalement des Winforms, vous serez isolé de ces modifications – elles ne devraient vous affecter que si vous utilisez directement WinAPI pour créer vos fenêtres ou dessiner votre boutons.
Il est recommandé de toujours concevoir votre produit en fonction de la dernière version du système d’exploitation, car vous devez également encourager votre client à mettre en œuvre ces mises à jour – IOW vous ne devez pas demander à votre client de ne pas installer mettre à jour xyz car votre application ne fonctionnera pas contre elle – surtout si cette mise à jour est une mise à jour de sécurité critique
le test des différences entre les versions du système d’exploitation doit être effectué par l’équipe d’assurance qualité et doit être indépendant de ce qu’il y a sur le serveur de génération
vous ne voulez pas que votre serveur de compilation soit tellement isolé du processus de mise à jour de la société que lorsque vous les appliquiez, il injecte du silicium fondu partout. IOW, plus vous attendez pour mettre à jour, plus le risque que quelque chose ne se passe pas correctement et de façon catastrophique augmente. Les mises à jour petites et fréquentes / incrémentielles sont moins risquées que les mises à jour en masse une fois par décennie 🙂

Les mises à jour du serveur de build sur lesquelles vous devez être prudent sont les contrôles tiers ou les mises à jour de la bibliothèque – elles peuvent souvent contenir des modifications brisées ou un comportement considérablement modifié. Ils devraient vraiment être programmés et suivis d’une série de tests à la recherche de modifications.

Virtualiser!

En utilisant des fonctionnalités telles que VMWare Server, vous pouvez créer un script pour le lancement et la suspension de machines virtuelles. Donc, vous pouvez script CV VM, SSH pour lancer la construction, copier, VM suspendre, répéter. (Je dis cela, mais j’ai abandonné mon travail là-dessus. Pourtant, je progressais à ce moment-là.)

En outre, vous pouvez faire confiance à vos fournisseurs de système d’exploitation. Vous ne pouvez pas

Ils ont un intérêt pour la compatibilité. Si vous construisez sur Windows XP, il est presque certain de fonctionner sur XP SP3, Vista et Windows 7.

Si vous construisez sur RedHat Enterprise 5, il serait préférable de travailler sur 5.1, 5.2, 5.3, 5.4, etc.

D’après mon expérience, cela s’est bien passé jusqu’à présent pour moi et je recommande de construire sur vos versions de système d’exploitation les plus basses. Avec les trucs Linux en particulier, j’ai trouvé des versions plus récentes reliées à des bibliothèques plus récentes, non disponibles sur les anciennes versions.

Bien sûr, cela ne fait pas de mal de tester votre code sur une copie du serveur de déploiement. Tout dépend de la façon dont vous voulez être.

Désactivez le serveur de compilation sur le réseau. Vous n’avez donc pas à vous soucier de l’installation des mises à jour de sécurité. Ne chargez que la source depuis un CD, une clé USB ou tout autre moyen.

Retwigz-le à la fin de votre cycle de publication et laissez toutes les mises à jour se produire.

Eh bien, pour le processus le plus stable, j’aurais deux serveurs de génération, “Build with Initial config, Build with update config” et deux serveurs de test de test automatique avec des différences similaires. Utilisez la virtualisation pour le faire de manière efficace et scripturable.