Wir versuchen, die neue Toolkette zum Erstellen und Bereitstellen einer CoreCLR-Website von ASP.NET 5 (vNext) für einen Servercluster zu verwenden. Zwischen den Änderungen der neuen Kompilierung und den Änderungen an TFS weiß ich nicht, wie alles jetzt erstellt und bereitgestellt wird. Das Szenario ist wie folgt:ASP.NET 5 (vNext) Bereitstellung über TFS 2015
- On-Premise-Steuerung TFS für Quelle und bauen Agent
- ASP.NET Targeting 5 unter CoreCLR über IIS gehostet
Fragen sind:
Verwendung TFS für Continuous Integration-Builds (und hoffentlich die Bereitstellung auf einem IIS-Server vor Ort), wie wird dieser neue Anwendungstyp erstellt und bereitgestellt?
Es scheint, dass MSBuild immer noch verwendbar sein kann, um auf eine .sln-Datei zu zeigen, um indirekt dnu.exe aufzurufen, ist das korrekt? Ist das der richtige Weg, dies jetzt zu tun?
Sollten wir stattdessen eine Skript-Erstellungsaufgabe ausführen, um stattdessen dnu.exe auszuführen?
Wie werden diese neuen CoreCLR-Builds bereitgestellt? Nur eine direkte Kopie in ein Verzeichnis auf einem Remote-Computer?
Dies ist eine neue Anwendung und wir verwenden eine mehrschichtige Anwendungsarchitektur, in der sich die DAL- und Geschäftslogik in ihren eigenen CoreCLR-Projekten befinden, wenn dies einen Unterschied macht.
Vielen Dank im Voraus für ein wenig Licht auf die Situation.
Sorry, aber die Bereitstellung mit Msbuild ist einfach falsch. Es muss einen msdeploy-Schritt geben, der denselben Satz von beförderten Binärdateien annimmt und an das Ziel sendet. Ob parameter.xml oder powershell verwendet werden, um die Konfiguration zu finalisieren, ist akademisch. Gegenwärtig ist Standalone-TFS vNext für eine ordnungsgemäße Versionsverwaltung ungeeignet und einige zusätzliche Elemente wie Octopus Deploy sind erforderlich. –
+1, voll und ganz einverstanden, und ich würde sogar hinzufügen, dass TFS nicht (cl) darauf abzielt, im Release-Management-Raum zu sein, und sollte nicht (ab) als solches verwendet werden. Dies ist der Punkt, an dem release-process-basierte Anbindungen an CI-Build-Systeme zu einem solchen Alptraum für alles andere als eine einfache und einfache Umgebung werden. Hier kommen Werkzeuge wie Octopus Deploy zum Einsatz. –