3. DevTools Ecosystem

3.1. Rationale

  • Ekosystem narzędziowy

  • Architektura

  • Skalowanie

3.2. Ekosystem wewnętrzny i zewnętrzny

  • Dla subkontraktorów

  • Musi być wpięty do wspólnego LDAP lub AD

  • Czy jest sens robienia i utrzymywania dwóch ekosystemów

  • Czy dając subontraktorowi dostęp do naszego ekosystemu, to on nie wie za dużo

  • Czy na 100% mamy wszystko ukryte by default, i to się nie zmieni (np. któryś z liderów zespołów współpracujący z innym zespołem zbyt obszernie otworzy dostęp (dla wszystkich)

  • Tworzymy template repozytorium, z wszystkim skonfigurowanym i wpiętym

  • Ważniejsze jest robienie Code Review na kodzie podkontraktorów, niż na własnym, bo w zespole rozmawiamy, a kontraktor dostarcza Wam gotowe rozwiązanie, a jak wcześnie nie zrobicie inspekcji, to może: a) robić kod niezrozumiały b) wybrać technologie, frameworki lub praktyki u Was nie stosowane co podniesie koszt utrzymania

  • System Code Review, ale również SonarQube pokazują problemy w kodzie

  • W tych systemach da się by default zobaczyć kontekst problemu (czytaj zobaczyć kod źródłowy pliku) co w konsekwencji prowadzi do tego, że ktoś inny ma całkowity dostęp do Twojego kodu źródłowego

  • Configuration as a Code jest life-saver

3.3. Architecture

../_images/ecosystem-big-picture1.png

3.4. Alternatives

../_images/ecosystem-tools.png