A csapat kiadási folyamata

  • 2 perc

A DevOps-eljárás létrehozásának első lépése a jelenlegi folyamat értékelése. Ez a következő elemzést jelenti:

  • A meglévő összetevők, például az üzembehelyezési csomagok és a NuGet, valamint a tárolótárak.
  • A meglévő tesztkezelési eszközök.
  • A meglévő munkafelügyeleti eszközök.
  • Migrálási és integrációs stratégiák ajánlása.

Tegyük meg ezt a Tailspin csapata esetében, és lássuk, hogyan lehet segítségünkre ebben a DevOps.

Miután Irwin, a termékmenedzser távozik, Amita azt mondja: „Segítségre van szükségünk. Nem tudom, hogy mikorra kell megcsinálni ezeket a javításokat, de biztos, hogy záros határidőn belül. A gyors átfutás nálunk nem opció. Ráadásul az új Space Game webhelynek meg kell várnia, amíg megoldjuk ezt a zűrzavart, és ez a játék gyorsan jön."

Andy Marára néz. "Ez sok, hogy az első néhány hétben."

„Semmi gond – válaszolja Mara –, esetleg elmagyarázhatnátok nekem, hogyan működnek itt a dolgok. Hogyan jut el egy játék a fejlesztőktől az éles üzemig?”

„Ez remek kérdés – mondja Andy –, "Nem tudom, hogy tudunk-e egyszerű választ adni, de próbáljuk meg."

A csapat úgy dönt, hogy elmennek egy kávézóba lazítani, és kötetlen megbeszélést folytatni. Együttesen próbálnak meg majd rájönni arra, hogy miért jelentkezik olyan sok probléma.

Kávézás közben Mara figyel, és megpróbál jegyzetelni. Nagyon sok információ elhangzik, rendszerezetlenül. A csapattal kapcsolatos általános megállapításai a következők:

  • Megközelítésük a vízesés logikáját követi. A vezetőség határozza meg a prioritásokat. A fejlesztők írják a kódot, és adják át a buildet a minőségbiztosítás számára. A minőségbiztosítással foglalkozók tesztelik a buildet, majd átadják az üzemeltetésnek üzembe helyezésre;
  • A vízesés megközelítés elfogadható lehet egy kis csapat számára, de itt a célok nem mindig egyértelműek, és úgy tűnik, hogy gyakran változnak.
  • A tesztelés egészen a folyamat késői szakaszáig várat magára. Ez azt jelenti, hogy a hibák javítása, illetve a módosítások végrehajtása nehezebb és drágább;
  • Nincs egyértelmű definíciója annak, hogy mit jelent a művelet . A csapat minden tagjának saját elképzelési vannak. Nincs olyan általános üzleti cél, amelyben mindenki egyetért.
  • A kód egy része egy központosított verziókövetési rendszerben található. Számos eszköz és szkript csak hálózati fájlmegosztásokon keresztül érhető el;
  • Sok a manuális folyamat;
  • A kommunikáció esetleges, e-mailben, Word-dokumentumokban és táblázatokban történik;
  • A visszajelzés szintén rendszertelen és nem következetes;
  • A plusz oldalon úgy tűnik, hogy a csapat kijön, és azt szeretnék, hogy a dolgok jobb.

Amikor az előtte tornyosuló jegyzetekre néz, Mara tudja, hogy ezt az információhalmazt rendszereznie kell. A rendszerezés megkönnyíti majd a folyamatok értékelését. Meggyőződése, hogy egy DevOps-megközelítés a csapat számos problémáját meg fogja oldani, de valahogy be kell mutatnia az álláspontját a csapatnak.

A DevOps-gyakorlatok gyakran a meglévő folyamatok megértésével kezdődnek. Ennek alapján már értékelni lehet, hogy mi működik jól, mi nem, és elsődlegesen minek a javítására kell összpontosítani.

Screenshot of a person taking notes on their tablet device.

Mara azt kérdezi: "Végeztek már valaha értékáram-leképezési gyakorlatot?"

Andy a szemeit forgatja, Amita sóhajt, Tim pedig azt mondja: „Nincs szükségünk több papírmunkára”.

Mara erre azt mondja: „Értem. Bízzátok rám.”

Annak örömére, hogy mindezt ráhagyhatták az új kollégára, mindenki visszatér a munkájához.