Ten artykuł jest również dostępny w:
Wyróżniamy trzy rodzaje zmian: błędy, funkcje i zmiany w infrastrukturze lub konserwacji systemu. Etap początkowy jest różny dla każdej zmiany, ale wszystkie one mają ten sam proces rozwoju, testowania i wdrażania.

Klient zgłosił błędy
Zawsze, gdy błąd jest zgłaszany do naszego działu obsługi klienta, jest on zgłaszany w naszym wewnętrznym biurze obsługi. Z naszego wewnętrznego działu obsługi technicznej błąd jest potwierdzany przez zespół QA. Zatwierdzone błędy są następnie eskalowane do naszego zespołu devsupport1 , który zajmuje się ich obsługą. Od tego momentu przechodzą one ten sam proces rozwoju, co nowe funkcje.

Cechy charakterystyczne
Cechy z mapy drogowej, które są wybierane do rozwoju, są zapisywane w kryteriach akceptacji przez menedżera produktu. Zanim funkcja zostanie wdrożona, jest ona omawiana i udoskonalana przez wszystkie zaangażowane zespoły.

Utrzymanie infrastruktury i/lub systemu
Istnieje kilka powodów, które powodują zmiany w naszej infrastrukturze/systemie.

Istnieją aktualizacje zabezpieczeń dla oprogramowania innych firm, od których zależy nasz produkt.
Dostępne są nowe wersje oprogramowania innych firm, od których zależy nasz produkt.
Zmiany w infrastrukturze/systemie są niezbędne do ulepszenia naszego produktu lub procesów pracy.

Te zmiany, które są wybierane do rozwoju, są następnie omawiane, a następnie wdrażane przez nasz zespół rozwojowy, w taki sam sposób, w jaki wykonywane są funkcje. Ze względu na naszą politykę bezpiecznego rozwoju nadajemy priorytet uaktualnieniom bezpieczeństwa.

Proces rozwoju
Proces ten składa się z następujących etapów:

Dyskusja: Kryteria akceptacji są spisane/poprawione dla zamierzonej zmiany. Gwarantuje to, że każdy, kto pracuje nad daną cechą/zmianą, wie, jaki jest zamierzony efekt końcowy. Naszym celem jest wprowadzenie wielu małych poprawek w stosunku do dużych zmian.
Rozwój: nad kodem pracuje co najmniej dwóch programistów. Używamy rozwoju sterowanego testami. Testujemy nasz kod za pomocą automatycznych testów jednostkowych, integracyjnych, funkcjonalnych i akceptacyjnych. Wszystkie nowe i istniejące testy są wymagane do przejścia przed przejściem do etapu przeglądu kodu.
Przegląd kodu: wszystkie zmiany są przeglądane przez co najmniej jednego innego dewelopera, który nie pracował nad kodem. Tutaj sprawdzamy, czy kod jest zgodny ze standardami. Używamy OWASP top102 do sprawdzania luk w kodzie. Zmiana nie może przejść do następnego etapu, dopóki nie zostanie rozwiązana, a wszystkie zmiany w kodzie nie zostaną zrecenzowane.
Zapewnianie jakości: Zmiany są testowane przez zespół QA. Jeśli zmiany nie spełniają kryteriów akceptacji, standardów dostępności lub mają inne problemy, cały proces wraca do fazy rozwojowej.
Połączyć: Wszystkie zmiany są łączone z wersją rozwojową naszego produktu.
Wydanie: Codziennie wydajemy nową wersję naszego oprogramowania:
Umieszczamy najnowszą wersję rozwojową w naszym środowisku do testów.
Przeprowadzamy test akceptacyjny na całej aplikacji.
Jeśli wszystko przejdzie pomyślnie, wdrażamy wszystkie zmiany w produkcji.

||Notacje
Zespół devsupport to zespół programistów, który pomaga przy obsłudze naszego produktu. Większość naszych błędów jest rozwiązywana przez ten zespół.
OWASP top10 to lista najczęstszych błędów. Lista ta znajduje się na stronie OWASP: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project||
Czy ten artykuł był pomocny?
Anuluj
Dziękuję!