In meinem Unternehmen erforschen wir derzeit verschiedene Strategien zur Beschleunigung unserer CI-Builds. Wir haben unsere Builds profiliert und festgestellt, dass wir durch einen I/O-Engpass eingeschränkt sind. Wir haben einige Optionen, um damit in naher Zukunft fertig zu werden (~ 1-2 Monate), aber würden wirklich gerne eine Verbesserung sehen jetzt.Ist es sinnvoll, eine Ramdisk auf einem Build-Server zu verwenden?
Ich schlug vor, eine Ramdisk als Checkout- und Buildfile-Speicherort zu verwenden. Die Build-Ausgaben und Protokolle würden natürlich auf einer physischen Platte gespeichert werden.
Ist das eine vernünftige Sache oder gibt es signifikante Nachteile bei diesem Ansatz? Ich suche nicht nach Antworten, die die Hardwareseite der Dinge betreffen, sondern eher, wenn die Interaktion zwischen gewöhnlichen Build-Systemen (z. B. MSBuild) und einer Ramdisk irgendwelche Probleme verursacht und wenn es andere Risiken gibt, die ich beachten muss.
Eine einfache Anmerkung: Ich nehme an, Sie sprechen hier über nächtliche Builds? In diesem Fall müssen Sie natürlich das Maximum an Builds von Grund auf neu testen und testen. Wenn es tägliche Builds wären, schlage ich vor, die Buildzeit um maximal 5 Mn zu halten, damit Entwickler ein schnelles Feedback zu möglichen Problemen bekommen können Jedes commit: In diesem Fall ist es meistens nützlich, * incremental * compilation zu machen, dh, mache einfach ein svn (hg/git/etc.) update, und benutze Make (oder Ant, Nant, etc) um zu re -compile was sich geändert hat. Mit einem gut geschriebenen Makefile könnte es auch die Dinge dramatisch beschleunigen. Nur meine 0.02 € :-) –
Ich spreche hier über CI (Build nach jedem Commit). Wir nutzen bereits inkrementelle Builds dafür, aber danke. –
@Christophe Muller, eine generelle Aussage machen, dass ein Build "maximal 5 Mn" sein sollte, ist wirklich lächerlich, ohne die Umgebung, die Größe und die Anforderungen des Builds zu kennen. Wir haben ein Produkt, das auf einem CI-Server läuft und in weniger als zwei Minuten kompiliert und verpackt wird. Wir haben ein anderes Produkt, das mehrere .NET-Lösungen, mehrere native Windows-Dienste, mehrere Adobe Flex-Projekte, Komponententests, Codeabdeckung, Paketierung und automatisierte Bereitstellung in einem Test-Rack umfasst. Der gesamte Prozess (nicht bei jedem Check-in) läuft über zweieinhalb Stunden *. –