Umownie projekty można podzielić na
Green Field – projekty budowane w zupełnie nowym środowisku. Te projekty wydają się prostsze, bo wszystko można zrobić „jak się chce”. Wyzwaniem w takim projekcie może być brak doświadczenia z nowymi rozwiązaniami i brak potwierdzenia sprawności danej technologii w praktyce. Dużo czasu musi być poświęcone na sprawdzenie możliwych opcji i wybór tej najlepszej.
Brown Field – projekty budowane w istniejącym środowisku z istniejącymi innymi aplikacjami, systemami, zależnościami. Ten typ projektu łączy się z często z bieżącym utrzymaniem istniejących aplikacji. Inny problem to opór stawiany przez administratorów istniejącego systemu, których głównym zadaniem jest utrzymanie aplikacji „as is”. Czasami ryzyko związane z modyfikacją istniejącego systemu jest tak duże, że zamiast pracować nad „brown project”, praca zostanie przekształcona w „green project” polegający na zbudowaniu zupełnie nowego systemu.
Oba typy projektów charakteryzują się też różnego rodzaju narzędziami pozwalającymi kontrolować, co się dzieje:
System of record – są to systemy, których głównym zadaniem jest dokładne śledzenie stanu systemu, co może być osiągnięte przez dokładne opisanie wszystkich zmian. Ten typ systemu jest ważniejszy w brown field project, bo tam trzeba pilnować tego co już jest.
System of engagement – jest budowany zazwyczaj z myślą o kliencie, pozwala priorytetyzować pracę z punktu widzenia klienta. Jest on bardziej specyficzny dla DevOps, ale nie wyklucza się z system of record. Systemy te pozwalają też zespołowi śledzić kto i za co jest odpowiedzialny.
W pracy DevOps trzeba (oczywiście) pracować z użytkownikami, których można podzielić na kilka kategorii:
Canary – użytkownicy, którzy bez powiadomienia o tym – pracują z nowymi rozwiązaniami i niestety jeśli coś jest nie tak, to praca tego człowieka jest najbardziej narażona na problemy. Ten typ użytkownika może nie wiedzieć o tym, że coś jest „na nim testowane”, całkiem jak kanarki przebywające z górnikami pod ziemią. Ich rola była brutalna – jeśli ulatniał się gaz, kanarek umierał pierwszy ostrzegając w ten sposób górników
Early adopter – użytkownicy, którzy na ochotnika świadomie zgadzają się na testowanie oprogramowania.
Użytkownicy (standardowi) – uzyskują dostęp do aplikacji na koniec, kiedy dana funkcjonalność jest już przetestowana przez canary i early adopters.
Nie stronimy też od pomiaru postępu projektu poprzez KPI. Pozwalają one śledzić, jak dobrze, albo jak źle jest realizowana dana usługa, albo dane rozwiązanie. Część z KPI będzie powiązana z wartościami wyliczanymi, ale inne mogą pochodzić z subiektywnej oceny użytkownika. Zwykle ocenie podlega:
- prędkość uzyskiwania zmian (liczba release, build itp.),
- efektywność – jak np. liczba serwerów na jednego administratora, wydajność systemu,
- jakość i bezpieczeństwo – ile razy coś się nie udało, np. nie udało się dostarczenie nowej wersji aplikacji, albo aplikacja była niedostępna, ile luk (bug) w oprogramowaniu zostało znalezionych, jakie jest pokrycie kodu przez testy, czy SLA jest osiągnięte, ile czasu zajmuje rozwiązanie incydentu,
- kultura – czy programiści są zadowoleni ze swojej pracy, czy odchodzą z firmy itp.
