Jaka jest różnica między Pipeline a Release Pipeline w lazurowych programistach?


14

Plik yaml jest generowany podczas wybierania tej opcji pokazanej poniżej:

wprowadź opis zdjęcia tutaj

W tym pliku yaml możesz zdefiniować cały cykl wdrażania, zaczynając od restore -> build -> run tests -> publish and -> deploy to azure app service web app.

dlaczego więc istnieje opcja wydań? Jeśli mogę zdefiniować cały cykl życia za pomocą Pipelines -> Pipelinesopcji, jaki jest cel tej Pipelines -> Releasesopcji?

wprowadź opis zdjęcia tutaj


Czy poniższa odpowiedź może pomóc Ci osiągnąć to, czego chcesz? Jeśli tak, możesz zaakceptować odpowiedź, aby inni użytkownicy SO mogli zobaczyć, czy rozwiązanie działa. Jeśli nadal masz problemy, zostaw komentarz tutaj :-)
Frank Wang-MSFT

Odpowiedzi:


16

Pipelines to nazwa najnowszego interfejsu użytkownika DevOps dla kompilacji. W starym interfejsie wygląda to tak: wprowadź opis zdjęcia tutaj

Można powiedzieć, że Pipeline(lub kompilacja lub kompilacja potoku) reprezentuje CI (ciągła integracja) w Azure DevOps. Releasereprezentuje CD (ciągła dostawa) w Azure DevOps. Potok zwykle pobiera kod, buduje go, testuje i tworzy artefakt. Wersja bierze artefakt i uwalnia / wdraża go.

Wykorzystanie zależy od twojego projektu.

Jeśli masz mały projekt i nie ma potrzeby korzystania z funkcji Release (np. Warunki przed zatwierdzeniem i zatwierdzenia), możesz mieć Pipeline, jak wspomniano: restore -> build -> tests -> deployi nie ma potrzeby w Release.

Jeśli twój projekt jest duży i ma duży wkład deweloperów, dobrze jest mieć Pipeline, który buduje, uruchamia testy jednostkowe, wykonuje inną automatyzację i wyniki z artefaktem za każdym razem, gdy deweloper naciska na wspólne repo. Dzięki temu możesz mieć pewność, że wszystko się ułoży i testy integracji przebiegły pomyślnie. Pipeline może także zakończyć zadanie wydania / wdrożenia w środowisku programistycznym / serwerach do pracy wewnętrznej, użytkowania, testowania.

W dużych projektach nie trzeba wdrażać każdego push do wspólnego repozytorium. Możesz więc ustalić wydanie, które będzie odpowiedzialne za wdrożenie w środowisku produkcyjnym. Ma przeznaczone do tego funkcje, takie jak wstępne zatwierdzenie, więc wszyscy są zgodni, że jest to odpowiednia kompilacja (lub artefakt) do produkcji.


To nie jest dokładnie dokładne, ponieważ potoki (jeśli są określone jako pliki YAML) również obsługują scenariusze wydania.
Daniel Mann

2
@DanielMann nie powiedziała przeciwnie, odpowiada na wędrówkę op, wyjaśniając różnicę między nimi
AymenDaoudi

2

Jak zauważono w dokumentach Microsoft, sekcja „Wydania” to ich rozwiązanie „Klasyczny edytor”: Link

Sekcja „Rurociągi” oferuje tworzenie rurociągów na dwa sposoby:

  1. Kod YAML
  2. Klasyczny edytor interfejsu użytkownika

To, co Classic w zasadzie przez nich rozumie, to oryginalny sposób tworzenia potoków Azure DevOps. Budujesz potok za pomocą interaktywnego edytora GUI. Rurociąg utworzony z YAML , z pomocą asystenta, jest nowszym sposobem .

To, co w sekcji „Rurociągi” zawiera głównie „Wydania”, to to, że pisząc kod YAML, można skonfigurować strategię CI / CD jako kod, w którym definicja Rurociągu żyje razem z kodem.

Ich najnowsze zasoby edukacyjne wskazują również na użycie YAML i tworzenie etapów kompilacji i wdrażania w tym samym potoku Wdrażanie aplikacji za pomocą Azure DevOps

Polecam:

  • Jeśli wolisz używać klasycznego edytora interfejsu użytkownika, użyj sekcji „Rurociągi” dla kompilacji i sekcji „Wydanie” dla wdrożeń;
  • Jeśli wolisz korzystać z YAML, po prostu skorzystaj z sekcji „Pipelines” dla kompilacji i wdrożeń i utwórz wieloetapowy potok.

Rurociąg z wieloma etapami


Naprawdę mylące jest to, jak nazywają rzeczy.
AymenDaoudi
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.