Korzystanie z szablonu procesu kompilacji TFS (przepływ pracy) podczas wdrażania

10

Zastanawiam się nad wykorzystaniem przepływów pracy kompilacji TFS do złożonych wdrożeń. Niektóre z nich mogą wymagać wdrożenia:

  1. Aplikacje i usługi internetowe
  2. Baza danych
  3. Raporty SSRS
  4. Pakiety SSIS
  5. Kto wie co jeszcze

Podoba mi się fakt, że mogę nadać przepływowi pracy kilka podstawowych parametrów, takich jak kompilacja do wdrożenia, a ona po prostu uruchomi się. Potencjalnie niektóre części mogą wymagać ludzkiej akceptacji i wiem, że przepływ pracy też sobie z tym poradzi. Przykładem może być użycie przepływu pracy do utworzenia skryptu zmiany z naszych projektów Visual Studio Database, ale grupa DBA będzie chciała zatwierdzić skrypt przed jego uruchomieniem.

Chcę wiedzieć, czy inni używali do tego „kompilacji” i jakie problemy zostały znalezione.

deployment builds workflows team-foundation-server John Saunders
źródło
Korzystamy z TFS 2010 do zarządzania naszymi kompilacjami / wdrożeniami. Nie mam dla ciebie szybkich odpowiedzi; ale gdy pojawią się problemy, napisz do mnie e-mail, a my możemy przynajmniej spróbować to rozwiązać.
Stephen Gross

Odpowiedzi:

1

Użyliśmy TFS do uruchomienia naszych kompilacji, ale użyliśmy msbuild do zbudowania naszych projektów. Główną zaletą jest to, że mamy skrypt kompilacji, który możemy zmienić i zachować kontrolę wersji. Dotyczy to przepływów pracy, np .: jak zbudujesz starszą wersję swojego projektu? Dzięki skryptowi kompilacji po prostu pobierasz starszą wersję z kontroli źródła i zaczynasz. Miło jest też móc się nim bawić i włączać / wyłączać różne opcje.

Jeśli nie masz pewności, że masz ustalony cykl kompilacji, prawdopodobnie możesz to zrobić, w przeciwnym razie posiadanie skryptu jest prawdopodobnie bezpieczniejszą i bardziej elastyczną opcją.

Carlo Kuip
źródło
Przepływy pracy to pliki .xaml przechowywane w kontroli źródła. Potrzebuję procesu, który rozgałęzia pliki .xaml wraz z kodem źródłowym. Bez wątpienia rozgałęziasz pliki msbuild wraz ze źródłem.
John Saunders
@JohnSaunders tak, rozgałęziamy nasze skrypty budowania. Fajnie, że konfiguracja twojego przepływu pracy jest przechowywana w pliku xml, ale jaki wpływ ma zmiana konfiguracji na elementy, które są w innej wersji twojego przepływu pracy (elementy pracy, zadania itp. W twoim projekcie również mieszczą się w tym samym przepływie pracy, prawda? ) Tam widzę ryzyko, zmieniając sposób, w jaki TFS obsługuje Twój projekt w locie.
Carlo Kuip,
Nie wiem o co ci chodzi. Zmiana szablonu procesu kompilacji nie zmieni elementów pracy. Co masz na myśli „elementy, które są w innej wersji twojego przepływu pracy”?
John Saunders
Szablon procesu stosowany podczas tworzenia projektu TFS tworzy przepływ pracy. Oznacza to, że jeśli utworzysz element roboczy, zostanie on powiązany z różnymi etapami tego przepływu pracy. Czy proces kompilacji będzie rozszerzeniem tego przepływu pracy, czy może jest oddzielny?
Carlo Kuip,
Przepraszamy, mylisz szablon procesu i szablon procesu kompilacji. Microsoft źle wybrał swoje warunki. Ponadto szablon procesu, którego używasz podczas tworzenia projektu zespołowego, nie tworzy żadnego przepływu pracy, o którym wiem.
John Saunders,