Ten artykuł jest również dostępny w:
Ten artykuł został przetłumaczony przy użyciu tłumaczenia maszynowego. Może zawierać błędy lub dziwnie brzmiące tłumaczenia. Mimo to uważamy, że warto go przeczytać w swoim ojczystym języku. Daj nam znać, czy ten artykuł okazał się pomocny, lub przekaż inne uwagi u dołu artykułu.

Wyróżniamy trzy rodzaje zmian: błędy, funkcjonalności oraz zmiany w infrastrukturze lub utrzymaniu systemu. Etap początkowy jest inny dla każdej ze zmian, ale wszystkie one mają ten sam proces rozwoju, testowania i wdrażania.

Błędy zgłaszane przez klientów
Kiedykolwiek błąd jest zgłaszany do naszego działu obsługi klienta, jest on również zgłaszany do naszego wewnętrznego działu obsługi klienta. Z wewnętrznego działu obsługi klienta błąd jest weryfikowany przez zespół QA. Poprawne błędy są następnie eskalowane do naszego zespołu devsupport1, który zajmuje się błędami. Od tego momentu, błędy podlegają temu samemu procesowi rozwoju, co nowe funkcje.

Cechy
Cechy z mapy drogowej, które są wybrane do rozwoju, są zapisywane w kryteriach akceptacji przez kierownika produktu. Zanim cecha zostanie zaimplementowana, jest dyskutowana i dopracowywana przez wszystkie zaangażowane zespoły.

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

Pojawiają się aktualizacje bezpieczeństwa dla oprogramowania firm trzecich, od którego zależy nasz produkt.
Pojawiły się nowe wersje oprogramowania firm trzecich, od których nasz produkt jest zależny.
Zmiany w infrastrukturze/systemie są potrzebne do ulepszenia naszego produktu lub procesów pracy.

Te zmiany, które są wybierane do rozwoju, są następnie omawiane i wdrażane przez nasz zespół programistów, w taki sam sposób jak funkcje. Biorąc pod uwagę naszą politykę bezpiecznego rozwoju, priorytetowo traktujemy aktualizacje bezpieczeństwa.

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

Dyskusja: Kryteria akceptacji są wypisywane/poprawiane dla zamierzonej zmiany. To zapewnia, że każdy, kto pracuje nad cechą/zmianą wie, jaki jest zamierzony efekt końcowy. Naszym celem jest wprowadzanie wielu małych ulepszeń zamiast dużych zmian.
Rozwój: co najmniej dwóch programistów pracuje nad kodem. Używamy rozwoju opartego na testach. Testujemy nasz kod za pomocą zautomatyzowanych testów jednostkowych, integracyjnych, funkcjonalnych i akceptacyjnych. Wszystkie nowe i istniejące testy muszą przejść pomyślnie zanim przejdą do etapu weryfikacji kodu.
Code review: wszystkie zmiany są przeglądane przez co najmniej jednego programistę, który nie pracował nad kodem. Tutaj weryfikujemy, czy kod jest zgodny z obowiązującymi standardami. Używamy top102 OWASP do sprawdzania podatności. Zmiana nie może przejść do następnego etapu, dopóki wszystkie uwagi nie zostaną usunięte, a wszystkie zmiany w kodzie nie zostaną ponownie przejrzane.
Quality Assurance: 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 etapu rozwoju.
Merge: Wszystkie zmiany są scalane do wersji rozwojowej naszego produktu.
Wydanie: Codziennie wypuszczamy nową wersję naszego oprogramowania:
Umieszczamy najnowszą wersję rozwojową na naszym środowisku staging do testowania.
Przeprowadzamy test akceptacyjny na całej aplikacji.
Jeśli wszystko przejdzie pomyślnie, wdrażamy wszystkie zmiany na produkcję.

Uwagi
Zespół devsupport jest zespołem programistów, którzy pomagają we wspieraniu naszego produktu. Większość naszych błędów jest rozwiązywana przez ten zespół.
Top10 OWASP jest listą najczęściej występujących podatności. Listę można znaleźć na stronie OWASP: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project||
Czy ten artykuł był pomocny?
Anuluj
Dziękuję!