SVN, virtualisation TeamCity / configuration matérielle requise

Question

J'essaie de rassembler les conditions requises pour qu'un nouvel environnement soit constitué de TeamCity exécutant Sql Server, de deux agents de construction (pour l'instant) et d'un référentiel SVN.

Il y a 6 développeurs et il y aura 5 solutions actives impliquées dans le processus CI pour le moment qui vont évidemment croître avec le temps. Aucune des solutions ne prend actuellement plus de 10 minutes à construire, elles ne sont donc pas très complexes en termes de complexité et de performances. loc.

Les projets de construction auront eux-mêmes besoin d'une instance de serveur SQL pour que les tests automatisés puissent s'exécuter. Je suppose qu'ils doivent être conservés séparément de l'instance TeamCity sql.

Quelqu'un peut-il suggérer une configuration matérielle appropriée pour les exécuter? Est-ce que le disque i / o sera plus important que la puissance réelle du processeur.

Puis-je utiliser tout cela sur un seul processeur, le raid et la virtualisation?

Devrions-nous utiliser Windows 2008 et Hyper-V?

J'ai toujours laissé les autres s'occuper des exigences du serveur et de la construction, mais maintenant je dois me salir les pieds.

Tout conseil bienvenu

Answer 1

Un point de données:

Notre environnement TeamCity est activé (si je me souviens bien) par un trio de serveurs à 8 cœurs dotés chacun de 32 Go de RAM, exécutant Windows 2008 et HyperV. Notre référentiel SVN est sur un serveur différent (pour des raisons historiques). Je pense que tout est maintenant sur un réseau SAN, pour des raisons de fiabilité (si l’un des hôtes tombe en panne, nous pouvons facilement déplacer les ordinateurs virtuels vers un autre hôte).

Nous disposons de 10 agents de génération, tous exécutés sur des ordinateurs virtuels. 4 d'entre eux sont utilisés pour les constructions droites; 6 d'entre eux sont utilisés pour les versions et pour exécuter des tests système (ce qui implique la coordination d'autres machines virtuelles dans les tests). Nous avons opté pour cette solution, car la durée de certains tests système est de 11 heures et nous ne souhaitons pas bloquer la file d'attente de génération. Nous avons des versions progressives - un projet n’est idéalement pas transmis au service de test tant qu’il n’a pas réussi les tests automatisés des unités et des systèmes.

Nous avons environ une douzaine de développeurs travaillant activement sur 3 ou 4 projets à la fois. Nous utilisons également TeamCity pour créer des correctifs logiciels et des versions de maintenance.

Dans votre scénario, je choisirais Windows 2008 et HyperV, dans la boîte la plus grande pour laquelle vous avez le budget. Les E / S de disque sont plus importantes que la puissance du processeur, mais avec plus de cœurs, vous pouvez plus facilement évoluer vers plus de VM. L'abondance de RAM affectée à chaque machine virtuelle évite les échanges et facilite la mise en cache, ce qui signifie moins d'E / S de disque. À un moment donné, vous pourriez envisager de disposer de deux boîtes ou plus, pour le basculement et parce qu'il est parfois moins cher d'acheter deux boîtes avec 32 Go de RAM que d'acheter l'option 64 Go pour une seule boîte.

Un des avantages de l’utilisation des machines virtuelles est que vous pouvez les capturer et les restaurer périodiquement. Chaque projet devrait probablement avoir sa propre instance de SQL Server.

Answer 2

Vous devriez consulter la section Comment de notre documentation: http: // confluence.jetbrains.net/display/TCD65/How+To ... Vous y trouverez "Estimer la configuration matérielle requise pour TeamCity". sujet. Cela aidera probablement.

Answer 3

Le lien dans le post précédent est cassé La suite est la bonne. http://confluence.jetbrains.com/display /TCD65/How+To...#HowTo...-hardwarerereirements