Skip to content

ZespolNumerJeden/zn1Web

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

89 Commits
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Production Build Status

VSTS Build Status

Production website

Produkcyjna wersja strony. http://ogarnij-agile.azurewebsites.net/

Pull requests dev -> master builds

VSTS Build Status

Staging website

Zawiera zmiany z pull requesta na master. Jeśli zachowanie strony będzie poprawne, to admin wciągnie zmiany na produkcję. http://ogarnij-agile-staging.azurewebsites.net

Development Build Status

VSTS Build Status

Development website

Zawiera stan z brancha development. http://ogarnij-agile-dev.azurewebsites.net/

Waffle.io work progress

Waffle.io - Columns and their card count

Zasady commitowania - pipeline CI & CD

  1. Każdy dev ma swojego brancha (moze miec kilka do różnych feature'ów)
  2. Po zbudowaniu na swojej maszynie WRAZ Z TESTAMI commituje na swojego brancha
  3. Jeśli na lokalnej maszynie build przechodzi to składamy pull request na development, lub bezpośrednio commitujemy na development.
    1. Jeśli złożyliśmy Pull Request (dalej PR):
      1. uruchomi się build naszego PR
      2. sprawdzamy status builda naszego PR (wchodzimy w szczegóły PR i szukamy poniższego okienka - klikamy Show all checks i widzimy status builda. Szczegóły pull requesta
      3. jeśli status wszystkich checków jest zielony, to możemy sami zaakceptować PR - przycisk Merge Pull Request
    2. Jeśli bezpośrednio commitowaliśmy na development, przechodzimy do następnego kroku.
  4. W tym momencie uruchomił się build brancha development. Jeśli będzie pozytywny to zmiany będą widoczne na wersji developerskiej strony
  5. Dokładnie sprawdzamy działanie strony z naszymi zmianami, zwracamy uwagę na inne błędy - jęsli się pojawią to tworzymy issue na tablicy.
  6. Jeśli strona działa prawidłowo - składamy pull request na master z development.
  7. Tu kończy się działanie deva.

Wkracza dev lead i testerzy.

  1. W tym momencie robi się build PR na mastera
  2. Jeśli status jest prawidłowy to dev lead sprawdza kod i akceptuje (lub nie) PR
  3. Po zmergowaniu, następuje kolejny build, jeśli jest ok, to zmiany trafiają na staging website
  4. Testerzy robią swoją pracę.
  5. Test lead akceptuje zmiany (Visual Studio Team Services)
  6. Zmiany trafiają na produkcję.

About

Aplikacja do zarządzania udziałem w konferencji

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published