18 KiB
Operacje dla programistów na darmowym CodeCamp.org
Ten przewodnik pomoże Ci zrozumieć nasz stos infrastruktury i sposób utrzymania naszych platform. Chociaż niniejszy przewodnik nie zawiera wyczerpujących szczegółów dotyczących wszystkich operacji, może on być wykorzystany jako punkt odniesienia dla Państwa zrozumienia systemów.
Wiedzmy, jeśli masz opinie lub zapytania i z przyjemnością wyjaśnimy.
W jaki sposób tworzymy, przetestowujemy i wdrażamy bazę kodową?
This repository is continuously built, tested and deployed to separate sets of infrastructure (Servers, Databases, CDNs, etc.).
Obejmuje to trzy etapy, które należy wykonać kolejno:
- Nowe zmiany (zarówno poprawki jak i funkcje) są scalane w naszym głównym oddziale rozwoju (
master
) za pomocą pull requestów. - Zmiany te przeprowadza się poprzez szereg zautomatyzowanych testów.
- Po przejściu testów wydamy zmiany (lub w razie potrzeby zaktualizuje) w celu wdrożenia naszej infrastruktury.
Budowanie ebazy kodowej - mapowanie gałęzi Git do wdrożeń.
Zwykle główny
(domyślna gałąź rozwojowa) jest scalona w gałąź
raz dziennie i jest uwalniana do odizolowanej infrastruktury.
To jest wydanie pośrednie dla naszych programistów i wolontariuszy. Jest ona również znana jako "etap" lub "beta".
Jest to identyczne z naszym żywym środowiskiem produkcyjnym w freeCodeCamp.org
, inne niż przy użyciu oddzielnego zestawu baz danych, serwerów, proxy internetowych itp. Izolacja ta pozwala nam przetestować bieżący rozwój i cechy w scenariuszu „produkcji”, nie wpływając na zwykłych użytkowników głównych platform FreCodeCamp.org.
Gdy zespół deweloperów @freeCodeCamp/dev-team
jest zadowolony ze zmian na platformie testowej, te zmiany są przenoszone co kilka dni do gałęzi aktualnej produkcji
.
To jest ostateczna wersja, która przenosi zmiany na nasze platformy produkcyjne na freeCodeCamp.org.
Testowanie zmian - Testowanie integracji i akceptacji użytkownika.
Stosujemy różne poziomy integracji i testów akceptacji w celu sprawdzenia jakości kodu. Wszystkie nasze testy są wykonywane przez oprogramowanie takie jak Travis CI i Azure Ruropeline.
Mamy testy jednostkowe do testowania naszych rozwiązań wyzwań, interfejsów API serwera i użytkowników klientów. Pomagają nam one przetestować integrację pomiędzy różnymi komponentami.
[!NOTE] Jesteśmy również w trakcie pisania testów użytkowników końcowych, które pomogą w replikowaniu scenariuszy prawdziwego świata, takich jak aktualizacja wiadomości e-mail lub wywołanie połączenia do API lub usług innych firm.
Łącznie te testy pomagają zapobiec powtórzeniu się problemów i upewnić się, że nie wprowadzimy błędu podczas pracy nad innym błędem lub funkcją.
Wdrażanie zmian - Przesyłanie zmian na serwery.
Skonfigurowaliśmy oprogramowanie do ciągłej dostawy, aby wprowadzać zmiany do naszych serwerów rozwojowych i produkcyjnych.
Po przepychaniu zmian do chronionych gałęzi uwalniania automatycznie uruchamia się budowę rurociągu dla gałęzi. Budowa rurociągów jest odpowiedzialna za budowę artefaktów i przechowywanie ich w chłodni do późniejszego wykorzystania.
Budowa rurociągu uruchamia odpowiedni rurociąg wydania, jeśli zakończy się pomyślnym uruchomieniem. Rurociągi wydania są odpowiedzialne za zbieranie artefaktów budowy, przenoszenie ich na serwery i przechodzenie na żywo.
Status kompilacji i wydań jest dostępny tutaj.
Uruchamianie budowy, testowania i rozmieszczenia.
Obecnie tylko członkowie zespołu deweloperskiego mogą przepychać do gałęzi produkcyjnych. Zmiany w produkcji*
gałęzie mogą lądować tylko poprzez szybkie połączenie w przód do przed
.
[!UWAGA] W nadchodzących dniach poprawilibyśmy ten przepływ do wykonania poprzez pull-requests, aby poprawić zarządzanie dostępem i przejrzystość.
Przesyłanie zmian do aplikacji testowych.
-
Skonfiguruj pilota poprawnie.
git zdalny -v
Wyniki:
origingit@github.com:raisedadead/freeCodeCamp.git (fetch) origingit@github.com:raisedadead/freeCodeCamp.git (push) upstream git@github.com:freeCodeCamp/freeCodeCamp.git (fetch) upstream git@github.com:freeCodeCamp/freeCodeCamp.git (push)
-
Upewnij się, że Twoja gałąź `` jest niesamowita i w synchronizacji z upstreamem.
git checkout master git fetch --all --prune git reset --hard upstream/master
-
Sprawdź, czy Travis CI jest przekazywany na gałęzi
główny
dla upstream.Testy ciągłej integracji powinny być zielone i PASSING dla
głównego
gałęzi.Sprawdzanie statusu w Travis CI (zrzut ekranu)
![Sprawdź status budowy w Travis CI](https://raw.githubusercontent.com/freeCodeCamp/freeCodeCamp/master/docs/images/devops/travis-build.png)Jeśli to się nie powiedzie, powinieneś zatrzymać i zbadać błędy.
-
Potwierdź, że możesz utworzyć repozytorium lokalnie.
npm uruchom czysto i rozwiń
-
Przenieś zmiany z
mistrza
doetapu produkcji
poprzez szybkie scalaniegit checkout production-staging git merge master git push upstream
[!NOTE] Nie będziesz w stanie wymusić wypchnięcia i jeśli przepisałeś historię w każdym razie, te polecenia będą się błędne.
Jeśli tak się stanie, być może zrobiłeś coś niepoprawnego i po prostu powinieneś zacząć od nowa.
Powyższe kroki automatycznie uruchomi się na rurociągu budowy dla gałęzi etap produkcji
. Gdy kompilacja zostanie zakończona, artefakty są zapisywane jako pliki .zip
w chłodni do pobrania i wykorzystania później.
Rurociąg uwalniania jest uruchamiany automatycznie, gdy nowy artefakt jest dostępny z podłączonego rurociągu budowy. Dla platform testowych ten proces nie wymaga ręcznego zatwierdzania, a artefakty są wysyłane na serwery CDN i API klienta.
[!TIP|label:Estimates] Zwykle kompilacja trwa ~20-25 minut, a następnie uruchomienie wydania, które zajmuje ~15-20 minut dla klienta, i ~5-10 minut aby API było dostępne na żywo. Od wypychania kodu do bycia na platformach do testowania, cały proces zajmuje łącznie ~35-45 minut.
Ładowanie zmian w aplikacjach produkcyjnych.
Proces ten jest w większości taki sam jak platformy testowe, z kilkoma dodatkowymi kontrolami. Chodzi o to, aby mieć pewność, że nie niszczymy nic na wolnym CodeCamp.org, który widzi setki użytkowników z niego korzystających w każdej chwili.
NIE wykonuj tych poleceń, chyba że sprawdziłeś czy wszystko działa na platformie testowej. Nie powinieneś omijać ani pomijać żadnych testów testowania przed kontynuowaniem testu. |
---|
-
Upewnij się, że Twoja gałąź
stopniowania produkcji
jest niesamowita i w trakcie synchronizacji z górnym biegiem czasu.git checkout production staging git fetch --all --prune git reset --hard upstream/production-staging
-
Przenieś zmiany z
etapu produkcji
naprąd produkcyjny
poprzez szybkie połączenie w przódgit checkout production-current git scalge production-staging git push upstream
[!NOTE] Nie będziesz w stanie wymusić wypchnięcia i jeśli przepisałeś historię w każdym razie, te polecenia będą się błędne.
Jeśli tak się stanie, być może zrobiłeś coś niepoprawnego i po prostu powinieneś zacząć od nowa.
Powyższe kroki automatycznie uruchomi się na rurociągu budowy dla gałęzi prądu produkcyjnego
. Gdy budowniczy artefakt będzie gotowy, uruchomi on proces uwalniania.
[!TIP|label:Estimates] Zwykle kompilacja trwa ~20-25 minut.
Dodatkowe kroki dla działań kadrowych
Jeden z uruchomień wydania jest uruchomiony, członkowie zespołu deweloperów otrzymają automatyczny ręczny e-mail z interwencją. Mogą one zatwierdzić lub odrzucić uruchomienie wydania.
Jeżeli zmiany działają ładnie i zostały przetestowane na platformie testowej, można je zatwierdzić. Homologacja musi zostać udzielona w ciągu 4 godzin od uruchomienia zwolnienia, zanim zostanie automatycznie odrzucona. Administracja może uruchomić ponownie uruchomienie ręcznie dla odrzuconych uruchomień, lub poczekać na następny cykl zwolnienia.
Dla personelu:
Sprawdź swój adres e-mail, aby uzyskać bezpośredni link lub przejść do panelu wydania po zakończeniu kompilacji. |
---|
Gdy jeden z członków personelu zatwierdzi wydanie, rurociąg przepycha zmiany na żywo na serwery CDN i API freeCodeCamp.org. Zwykle zajmują około 15-20 minut dla klienta i około 5 minut dla serwerów API dostępnych na żywo.
[!TIP|label:Estimates] Uruchamianie wydania zajmuje zazwyczaj ~15-20 minut dla każdej instancji klienta i ~5-10 minut dla każdej instancji API, aby była dostępna na żywo. Od wypychania kodu do życia na platformach produkcyjnych cały proces zajmuje łącznie ~90-120 min (nie licząc czasu oczekiwania na zatwierdzenie personelu).
Stan budowy, testowania i wdrożenia
Oto bieżący test, kompilacja i stan rozmieszczenia bazy.
Typ | Oddział | Status | Pulpit |
---|---|---|---|
CI Testy | mistrz |
Przejdź do panelu stanu | |
CI Testy | etapy produkcji |
Przejdź do panelu stanu | |
Zbuduj rurociąg | etapy produkcji |
Przejdź do panelu stanu | |
Rurociąg uwolnienia | etapy produkcji |
Przejdź do panelu stanu | |
CI Testy | prąd produkcyjny |
Przejdź do panelu stanu | |
Zbuduj rurociąg | prąd produkcyjny |
Przejdź do panelu stanu | |
Rurociąg uwolnienia | prąd produkcyjny |
Przejdź do panelu stanu |
Wczesny dostęp i testy beta
Witamy w przetestowaniu tych wydań w trybie "publicznego beta testowania" i uzyskujemy szybki dostęp do nadchodzących funkcji platformy. Czasami te funkcje/zmiany są określane jako następne, beta, etap, itd. wymiennie.
Twój wkład poprzez informacje zwrotne i raporty o błędach pomoże nam stworzyć platformy produkcyjne na freeCodeCamp. rg
bardziej odporny, spójny i stabilny dla wszystkich.
Dziękujemy za zgłaszanie błędów, które napotkasz i pomoc w ulepszeniu freeCodeCamp.org. Jesteś skalisty!
Identyfikacja przyszłej wersji platform
Obecnie publiczna wersja beta testowa jest dostępna na stronie:
dev
[!NOTE] Nazwa domeny jest inna niż
freeCodeCamp.org
. Ma to na celu zapobieganie indeksowaniu wyszukiwarek i unikanie dezorientacji dla regularnych użytkowników platformy.
Identyfikacja obecnej wersji platform
Obecna wersja platformy jest zawsze dostępna pod adresem freeCodeCamp.org
.
Zespół dev-team scala zmiany z gałęzi produkcyjnej
na produkcję, prąd
po ich wydaniu. Najlepszym zatwierdzeniem powinno być to, co widzisz na żywo na stronie.
Możesz zidentyfikować dokładną wersję, odwiedzając dzienniki budowy i wdrożenia dostępne w sekcji statusu. Alternatywnie możesz również wypchnąć nas w kontrybucji na czacie w celu potwierdzenia.
Znane ograniczenia
Istnieją pewne znane ograniczenia i kompromisy podczas używania wersji beta platformy.
-
Wszystkie dane / osobisty postęp na tych platformach beta
NIE zostanie zapisany ani przeniesiony
do produkcji.Użytkownicy wersji beta będą mieli oddzielne konto od produkcji. Wersja beta używa fizycznie oddzielnej bazy danych od produkcji. Daje nam to możliwość zapobiegania przypadkowej utracie danych lub zmianom. Zespół deweloperski może w razie potrzeby oczyścić bazę danych w tej wersji beta.
-
Nie ma gwarancji dotyczących czasu pracy i niezawodności platform beta.
Przewiduje się, że stosowanie będzie częste i w przypadku szybkich iteracji, czasami wielokrotnych razy dziennie. W rezultacie pojawi się nieoczekiwany czas przestoju lub uszkodzona funkcjonalność wersji beta.
-
Nie wysyłaj regularnych użytkowników na tę witrynę w celu potwierdzenia naprawienia
Witryna beta jest i zawsze wspierała rozwój lokalny i testowanie, nic innego. Nie jest to obietnica co nadchodzi, ale gwiazdka tego, co się sprawdza.
-
Strona znaku może wyglądać inaczej niż produkcja
W Auth0 używamy lokatora testowego dla freecodecamp.dev i dlatego nie mają możliwości ustawiania domeny niestandardowej. To sprawia, że wszystkie wywołania zwrotne przekierowania i strona logowania pojawiają się w domenie domyślnej, takiej jak:
https://freecodecamp-dev.auth0.com/
. Nie ma to wpływu na funkcjonalność tak blisko produkcji, jak to możliwe.
Kwestie związane ze sprawozdawczością i pozostawienie opinii
Proszę otworzyć nowe problemy do dyskusji i zgłaszania błędów. Możesz oznaczyć je jako wydanie: next/beta
dla triage'u.
Możesz wysłać e-mail do dev[at]freecodecamp.org
jeśli masz jakieś zapytania. Ponieważ zawsze wszystkie luki w zabezpieczeniach powinny być zgłaszane do zabezpieczeń[at]freecodecamp.org
zamiast publicznego trackera i forum.