Proces tworzenia aplikacji internetowych - kontrola wersji, śledzenie błędów, testowanie jednostek, wdrażanie

Question

Opisz proces, którego używasz do tworzenia aplikacji internetowych na niezbyt wysokim poziomie, koncentrując się na VC, śledzeniu błędów, kontroli jakości, testowaniu jednostkowym, wdrażaniu i cokolwiek innego podobnego (pomijając aspekt planowania/komunikacji klienta).

Jestem nowy w tej dziedzinie, więc moim przykrym przykładem (czytaj: nie użyłem tego procesu) jest bez wątpienia abit off, że tak powiem - zwróć uwagę na jego wady, abym mógł się nauczyć.

Np.

1. Utwórz repozytorium projektu na lokalnym serwerze SVN.
2. Tworzenie skryptów wsadowych/powłoki dla mapowań DNS.
3. Sprawdź projekt, rozpocznij pracę nad lokalną kopią roboczą.
4. Rozwijaj funkcje jako gałęzie.
5. Śledzenie błędów z Modliszkiem (link zatwierdza do błędów poprzez integrację SVN (nie ma pojęcia, czy to istnieje)).
6. Dokumentuj na bieżąco.
7. Wykonaj kontrolę jakości w oddziale.
8. Scal do bagażnika, gdy jest stabilny.
9. Testowanie jednostek?
10. Zatwierdź do repozytorium, gdy funkcja jest zaimplementowana i stabilna.
11. Kopiowanie wersji do znaczników w repozytorium. Na przykład./project/tags/rel-123/
12. Użyj narzędzia Phing, aby przesłać na serwer pomostowy. (Może ktoś proszę wyjaśnić dokładnie co serwer pomostowy jest używany do testowania poza „”?)
13. Zastosowanie Phing aby przygotować witrynę, do aktualizacji, skonfiguruj DB/wdrożyć itp

Answer 1

grubsza:

1. Tworzenie repozytorium w SVN
2. Sprawdzanie lokalną kopię roboczą w środowisku deweloperskim
3. Aktualizacja/popełnić zmiany często
4. wdrożyć ją na scenie z SVN tr unk użyciu niestandardowych wdrożyć skrypt
5. testów QA na scenie, raporty błędów w Mantis
6. Deweloperzy naprawiają błędy, znak jako rozwiązany
7. ponowne wdrażanie do etapu
8. testy QA błędów, zamyka jeśli ustalona
9. QA jest skończył, wykonać test regresji
10. instalacja do produkcji przy użyciu niestandardowych wdrożyć skrypt
11. Czy trochę tańca

Tworzymy także gałęzie dla przyszłych wersji lub funkcji. W końcu zostają scalone w bagażnik.

Nasze struktury db synchronizujemy z niestandardowym narzędziem do porównywania baz danych, które jest wykonywane podczas wdrażania.

Answer 2

1. Tworzenie/checkout HEAD wersji („głównej gałęzi”)
2. Develop kod i synchronizację z głównej gałęzi-co najmniej codziennie
3. Po rozwój odbywa się, pisać i jednostka uruchomić testy
4. Go przez przeglądu kodu i przedkłada cODE/zmiany w głównej gałęzi
5. Niech ciągły budowniczy uruchomić wszystkie testy jednostkowe i testy systemu/integracja na głównej gałęzi
6. Gdy wszystko jest gotowe, wiśnia wybrać wersje i zintegrować je do oddziału QA
7. Przeprowadź testy systemu i integracji, napraw zgłaszane błędy lub wycofaj, jeśli to konieczne; ten powtarza kroki 4-7
8. Po QA SIGNOFF, zintegrować zmiany QA zwolnić Rozgałęzienie
9. testy jednostkowe metę System/testy integracyjne na uwalnianiu oddziału
10. Deploy do produkcji i uruchomić testy zdrowie.

Serwer pomostowy to kopia środowiska produkcyjnego, która jest tak aktualna, jak to tylko możliwe. W moim bieżącym projekcie, jesteśmy w stanie utrzymać każde wydanie niezależnie od siebie, więc nasz "serwer pośredniczący" jest naszym serwerem produkcyjnym, dostępnym tylko z innego adresu URL.

Uwagi i discreprencies:

wszystkie kroki mają pewne różnice w zależności od wielkości projektu. Im większy projekt, tym większa korzyść z selekcji wiśni i separacji środowiska. W mniejszych projektach mogą one być po prostu pochłanianiem czasu i często są pomijane lub pomijane.

Aby wyjaśnić, istnieje stos rozwojowy, stos QA i stos etapów. W zależności od wielkości projektu kontrola jakości może być przeprowadzana na etapie produkcji, produkcja może być w fazie stopniowania lub w niektórych kombinacjach. Rozdzielenie pakietów Dev i QA jest najważniejsze.

W powyższych krokach przyjmuję, że zarówno kod, jak i odpowiednie dane są wersjonowane lub śledzone. Uwzględnienie procesu wydania i kompilacji, który uwzględnia dane kontrolne, sprawia, że ​​wydanie jest bardzo łatwe.

W przypadku małego i średniego projektu może istnieć oddział zwolnienia lub może nim nie być; zależy to od częstotliwości zmiany kodu. Ponadto, w zależności od częstotliwości zmiany kodu i wielkości projektu, możesz zintegrować pełną gałąź kontroli jakości z gałęzią Release lub specjalnymi wersjami cherry pick, aby zintegrować się z gałęzią wydania.

FWIW, Znalazłem "skrypty migracji" za mało wartościujące. Zawsze są jednorazowym scenariuszem z niewielkim ponownym wykorzystaniem i powodują, że wycofywanie jest bolesne w dupie. O wiele łatwiej, twierdziłbym, lepiej, aby aplikacja była kompatybilna wstecz. Po kilku wydaniach (gdy wycofanie jest zabawne), czyszczenie danych powinno być wykonane, jeśli to konieczne.

Answer 3

Stary post, ale interesujące pytanie!

Na moje przedsiębiorstwo teraz:

1. Utwórz nową GitHub repo
2. Konfiguracja Jenkins
3. Clone lokalnie
4. start oddział
5. Opracowanie i dodać testy (serwer, klient i e2e)
6. Zatwierdź za każdym krokiem i pobierz + rebase, aby zachować synchronizację oddziału
7. Gdy wszystko jest gotowe, wciśnij oddział na serwer: pre-commit szarpie wyboru i testów oraz blok jeśli nie ok
8. Tworzenie żądania ściągania dla branży
9. Tutaj Jenkins automatycznie przeprowadza testy na gałęzi i flagi go jako "zielone" lub "zepsute testy" bezpośrednio na żądanie pobrania
10. W ostatniej chwili 2 współpracowników zapoznają się z prośbą o pociągnięcie i ustalili swoje ustalenia (z powrotem do kroku 5).
11. Gdy wszystko jest zielone i dwóch kolegów się zgodziło, ostatni scala żądanie pobrania
12. Usunięcie oddziału na serwerze
13. Po przygotowaniu, wcisnąć nową wersję
14. Aktualna wersja dostać natychmiast wdrożone na platformie testowej
15. QA zatwierdzenia korekty i funkcje wprowadzone (powrót do 5 jeśli problem)
16. (TODO) oddelegowuje do pre-Prod o identycznych parametrach niż produkcja
17. instalacja do produkcji
18. Go przeprosić użytkowników za błędy wprowadzone;) i zgłosić je w menedżerze emisyjnej
19. zgłoszeń funkcji get i zgłosić je w menedżerze emisyjnej
20. cyklu restart przy krok 2