A 2018 Villámelőadás verseny jutalma egy Las Vegasi út volt az Atlassian Summitra, amit Nagy Géza nyert el a National Instruments-től. Géza élménybeszámolójából átérezheted az egész rendezvény hangulatát és hogy miért is érdemes repcsire ülni: 

Röpke 12 óra repülés és 6 óra autózás után megérkeztünk hétfő este a hotel Excalibur-ba, ami a külseje alapján egy középkor kastélyra emlékeztetett. Bár gyorsan csak „rágugliztunk” hogy hova kell érkeznünk, valahogy az élőben megpillantott rengeteg színben pompázó kastélytól elállt a lélegzet:

Hát igen, Las Vegas nem a visszafogottságáról híres.  Még aznap este felkutattuk a közleben levő Mandala Bay Convention Center-t, ahol majd másnap délután 4től kezdődött a móka. Miután sikerült tisztázni a regisztrációnál, hogy bizony 2 embert is hívhatnak Nagy Gézának, megkaptam a Summit Pass-omat amivel már szabadon lehetett közlekedni az Expo Hall (ahol a kiállítók foglaltál el a standjaikat), valamint az egyes előadótermek közöt.

És előadások, azok bizony voltak. Ahhoz hogy a nagyon sűrű programban eligazodjunk, kötelező az Atlassian alkalmazás. Össze tudjuk állítani a napirendünket, hogy hasznosan tölthessük az ottani időt, és ne kelljen folyamatoisan keresgélni az előadótermeket. Az előadások sokfélék lehettek, de az alkalmzásban könnyen kiválaszthattuk, hogy milyen szinten állunk, illetve milyen szoftvertermékek érdekelnek, így csak azokat a lehetséges előadásokat listázta. Miután sikerült összeválogatni az aznapi programot, szomorúan konstatáltam, hogy sok előadás ami érdekelnme ugyanabban az időpontban van. Kár hogy nem lehet osztódni. 

Minden nap legfontosabb programja: A KEYNOTE!

A keynote-on hangzanak el a legjobb hírek.

  • Milyen újdonságok várhatóak a jövőbeli release-ekben
  • Milyen területekre fog az Atlassian kocentrálni?
  • Milyen új alklamazásokat fognka integrálni a mostani ökoszisztémába
  • Valamint: mindig van valami meglepi: Ebben az esetben, a résztvevők ingyen Cloud license-t kaptak, amennyeben már rendelkeznek egy Server vagy egy DataCenter licensz-el!!!

Már csak ezért is megéri elmenni az Atlassian Summit-ra! 


Az első Summitozók első este ledobhatták az ékszíjat, az ilyen horderejű beszélgetésektől, de a legnagyszerűbb mégis az, hogy az előadók a legtöbb esetben bármikor megtalálhatóak voltak az Atlassian standoknál. Ha esetleg bármi kétségünk vagy kérdésünk maradt, nyugodtan odaballaghattunk hozzájuk, és szívesen kedélyesen elcsevegtek velünk arról, hogy mégis hogyan tudnának ők hozzájárulni a mi infrstruktúránk fejlesztéséhez.


Második nap: Az első nap viszonylag rövidre sikerült, de az alaphangot már sikerült megteremteni. A második nap, már eleve felkészülve érkezhettünk, a reggeli után már bele is vethettük magunkat a kiállítók standjainak felkeresésébe. Mindenki lelkesen prezentálta, hogy milyen appokkal készül a potenciális vásárlók meghódítására, vagy éppen milyen szuper új fejlesztéssel készülnek a mostani appjaikhoz.

Valyantis, StiltSoft, Resolution, PagerDuty... Mind mind képviseltették magukat valamilyen újdonsággal. Bob Swift-ék az új Automation appjukkal ültek standot, amivel pofonegyszerű lesz a repetitív feladatok automatizálása, Adaptavist-ék a ScriptRunnerhez készülnek egy Google CodeBlocks projket alapú Drag&Drop script írásra alkalmas app-al, az Atlassian pedig... Minden létező termékéhez külön standot állított ahol lehetett beszélgetni Atlassian-okkal, akik elmagyarázták, hogy az ő termékvonaluk hogy illik a profilba, és mivel tudnak a teljes ökoszisztémához  hozzájárulni. Nem is beszélve a nagyszerű merchandise-okról!  Jól tesszük, ha viszünk magunkkal valamilyen jegyzetelőalkalmatosságot, mert

Előadások a sikertörténetek kedvelőinek:

  • Hogyan tud az OpsGenie, Statuspage, JIRA Software együttműködni azért, hogy a lehető leggyorsabban és legpontosabban tájkoztathassuk a felhasználókat
  • Hogyan vezetette be a PDS Distribution a jogi csapatának a JIRA Software-t?
  • Hogyan üzemeltessünk egy 10000 usernél nagyobb Jira Servert?
  • A Johnson & Johnson hogyan migrállt 15 Atlassian alkalmazást DataCenterre


Ha valakit inkább a gyakorlatias megoldások érdekelnek: Téning kurzusok, ahol lépésről lépésre bekonfigurálhatunk egy teljes környezetet

Ha valaki nem szeret sokat egy helyben ülni: 15 perces gyorstalpalók, és villámelőadások! 


Végül de nem utolsósorban: Atlassian BASH!


Work hard, play hard!  Szuper koncert, finom sörök... Méltó megkoronázása egy nagyon tanulságos, és rengeteg információval szolgáló 3 napnak.


Na EZÉRT IS megéri Villámelőadás versenyen részt venni! 


Az idei verseny részleteiről itt olvashatsz: Atlassian Day 2019 - Villámelőadás Versenykiírás

The original idea of Ultimate Permission Manager stemmed from a consultancy project. One of our customers was anxious about the information potentially leaking, as they weren't sure who could view a rather sensitive Confluence page. This quickly made us realize the importance of permission transparency, in a time when there weren't any all-round solutions for this.

During the creation of a custom macro and a private add-on, we've had a vision to make this solution available for the whole Confluence community!

We set a goal to create a publicly available app on the Atlassian Marketplace which we believed would become a must-have solution for each and every Confluence team in the world. We created an online quiz called the Ultimate Permission Challenge, contributed to online training materials, catalyzed Meetups and conference presentations on Confluence Permissions. We worked hard to let everyone know about the importance of permission settings of Confluence and information management in general.

It took us months and years of research, tireless learning, questioning the status-quo, rewriting the core parts from the ground several times to meet the needs of even the largest Confluence customers with multi-node Data Center clusters. We are very proud of the high quality and fully functioning features we delivered.

Our hard work, endurance and faith have made our vision come true... in a different, unexpected, but beautiful way :)

Atlassian has acquired our app which means that the most popular features can be integrated into Confluence Data Center.

We are honored to help make Confluence even better with the fruits of our labor and feel that this is the perfect time to thank everyone who helped us achieve such an unbelievable result.

Thank you to all of our customers, evaluators, colleagues and friends who helped this project to be successful, and of course, Atlassian for their trust and efforts in making this happen.

Last but not least, we would like to thank our partners and the fellow vendors we work closely with for sharing so much knowledge with us, letting us share our learnings with you, and helping us evolve as individuals and as a company.

Goodbye Ultimate Permission Manager, we are excited for you to serve the greater good with Atlassian!

Although one of our apps has moved on, we develop all of our apps with the same care and passion:

To stay up-to-date with our apps, you can  check out our Marketplace vendor page here.

Happy collaboration to everyone!

Ez egy vendégposzt egy néhány fős Atlassian Expert csapattól, a StiltSofttól, akik a JIRA és a Confluence fehérorosz rajongói. A StiltSoft egy Atlassian Verified Vendor, akik többek között a Smart Attachments for JIRA, a Table Filters for Confluence és az Awesome Graphs for Bitbucket add-onokat fejlesztik. Ebben a blog posztban bemutatják, hogyan rendszerezhetők a feladatok és a csatolmányok JIRA-ban minimális ráfordítással és maximális hatékonysággal, valamint hogyan erősíti egymást a Smart Attachments for JIRA és a JIRA Email This Issue addon.

A JIRA feladatok teljes körű menedzsmentje az Email This Issue és a Smart Attachments add-onokkal

A világon egyre többen kezdik használni az Atlassian JIRA rendszerét projektmenedzsment céljából, előre meghatározott munkafolyamatok vagy fejlődés követésére. Mindezt egy platformon belül.

Az újabb és újabb add-onok és bővítmények az Atlassian Marketplace-en gyűlnek össze, és teszik élvezetesebbé a JIRA és más Atlassian termékek használatát.

Ebben a blog posztban két add-ont mutatunk be: ezek az Email This Issue és a Smart Attachments.

Az Email This Issue beállítása

Ez az add-on a JIRA-ban konfigurált bejövő és kimenő mail szerverek alapján működik. A bejövő szervernél a Mail Handlert is szükséges bekonfigurálni, hogy fel tudja dolgozni a külső email címekről érkező emaileket, és új feladatként vagy megjegyzésként adja hozzá már létező témákhoz.

Ezen kívül az email sablonokat is tudunk definiálni. Személyre szabható a HTML sablonban, Velocity kóddal további mezőkre hivatkozhatunk, az email tárgyában megjeleníthetünk custom field-eket, stb.

Továbbá többféle értesítés is létrehozható külső partnerek/ügyfelek vagy más JIRA használók számára, melyeket bizonyos JIRA események lefutásakor küld ki a rendszer. Akár beállíthatunk előre definiált automatikus válaszüzeneteket azoknak, akik benyújtanak egy kérést, és így tovább.

Ahhoz, hogy az emaileket minél jobban testreszabhassuk a megfelelő célokra, az email küldés kontextusát is meg lehet határozni. Megadhatjuk, hogy mely projektekre, feladatoktípusokra,  JQL lekérdezésekre, email sablonokra, küldőkre és email címekre vonatkozzon a kontextus.

Az Email This Issue lehetővé teszi, hogy az egyes szituációkra külön-külön kialakítsunk valamilyen email küldési szabályt, és meghatározzuk a használni kívánt email sablont.

Kérések menedzselése az Email This Issue-val

Ebben a blog posztban bemutatjuk annak a lokalizáló ügynökségnek a működését, amely a lokalizáló kéréseket kezeli a JIRA Email This Issue add-onon keresztül.

A játékfejlesztő cégekből érkező ügyfeleink gyakran adnak be olyan kéréseket, melyekhez rengeteg email lokalizációs fájl tartozik. Rövid videókat, a játék szereplőinek szóbeli utasításait, dokumentumokat, promóciós anyagokat és a felhasználók különböző csoportjaihoz tartozó felületi forrásokat csatolnak a kérésekhez.

Egy átlagos kérés 8-10 különböző formátumú fájlt tartalmaz. Ez csak további problémákat okoz a lokalizációs menedzsereknek a fordítási fájlok elhelyezésekor, és a felhasználóknak szánt, már lefordított fájlok kiválasztásakor.

A Email This Issue add-on megoldja ezeket a problémákat, és kezeli az összes ilyen típusú bejövő kérést, újakat hoz létre a hozzá kapcsolódó JIRA projektben, vagy új megjegyzésként hozzáadja már létező témákhoz.

Csatolmányok rendszerezése a JIRA feladatokon belül

A Smart Attachments a legjobb eszköz arra, hogy hatékonyan rendszerezzük a JIRA ügyek csatolmányait.

Ez az add-on lehetővé teszi, hogy kategóriákat hozzunk létre a csatolmányokon belül, amiket a továbbiakban a csatolmányok csoportosítására és gyorsabb elérésére is használhatunk. Továbbá ezeket a kategóriákat feladattípusokhoz rendelhetjük, így azok esetén fognak csak megjelenni. Beállíthatunk hozzáférési tilalmakat különböző felhasználóknak, csoportoknak vagy projekt szerepeknek

Alapértelmezés szerint az összes új kérésből érkező csatolmány a lokalizációs kategóriák fájljaiban tárolódik. Ahhoz, hogy a különböző csatolmányok automatikusan különböző kategóriákba kerüljenek, a projekt adminisztrátornak először konfigurálnia kell a post function-t, ami a fájlformátum alapján automatikusan elrendezi a csatolmányokat. Ez a művelet akkor fut le, amikor a lokalizációs menedzser a feladat státuszát megváltoztatja NyitottrólFolyamatban"-ra.

Amint a lokalizációs menedzser a csatolmány fordításához jut, tisztán látja a különböző fájlformátumokat a különböző mappákban.

Lokalizáció menedzsment és csatolt fájlok

A lokális források feltöltése alatt, a fordítók a Smart Attachments add-ont a dokumentumok verziók menedzselésére használhatják. Ezzel egyszerre több dokumentum verziót is követhetnek, és megjegyzéseken keresztül bármikor kérhetik a csapat segítségét.

Ha több lokalizációs menedzser dolgozik különböző típusú tartalmakon, mindegyikük kiválaszthatja azt a csatolmányt, amelyet hozzá szeretne adni az ügyfél emailjének végső verziójához.

Az Email This Issue add-onnak ez a funkciója lehetővé teszi a menedzsernek, hogy minél gyorsabban kiválassza azt a befejezett fájlt, amit az ügyfélnek szeretne küldeni. Ez biztosítja, hogy a feladatok konzisztensek maradjanak, és megakadályozza, hogy a csatolmány egy régebbi verzióját vagy az eredeti verziót küldjék vissza az ügyfélnek.

Megerősítő email küldése az ügyfélnek

A lokalizációs folyamat utolsó lépéseként a projekt menedzser megírja a záró emailt, és visszaküldi az összes lokalizált fájlt az ügyfélnek. Az Email This Issue lehetővé teszi a menedzsernek, hogy ezt közvetlenül a JIRÁ-ból tegye meg. Itt a projekt menedzser pontosan meg tudja adni, hogy kiknek szeretné küldeni az Emailt, kiválaszthatja a megfelelő email sablont és a levél további jellemzőit.

Minden csatolmány, ami a Csatolmány hozzáadása mezőben található, automatikusan hozzá lesz csatolva az emailhez.

A projekt menedzser a teljes levelezés történetet vissza tudja követni a feladat Emailek fülén.

Az add-onok együttes használata

Az Email This Issue és a Smart Attachments együttes használata nem egy lehetőség, hanem kötelező, abban az esetben, ha rendszeresen több csatolmány cserél gazdát email formájában. Az Email This Issue add-on lehetővé teszi a bejövő emailek gyors és hatékony feldolgozását, és szabályozza a külső felhasználók küldött emaileket. A Smart Attachments segíti a JIRA-ban nehezen kezelhető, emailben küldött tucatnyi csatolmány rendszerezését.

Próbáld ki az Email This Issue és a Smart Attachments add-onokat most! /en/2017/06/08/Comprehensive+Management+of+JIRA+Issues+with+Email+This+Issue+and+Smart+Attachments

A doboz jó

Legóztál valaha? Ha igen, biztosan tudod, milyen érzés megtalálni a megfelelő helyet a megfelelő darabnak. Gyerekjáték megépíteni bármit. A gondok akkor kezdődnek, amikor többen játszanak, és mindenki izgatott, hogy megvalósítsa saját álomépítményét.

Maradhatsz a dobozban…

Ha minden tulajdonságot lefejlesztesz, amit a felhasználóid szeretnének az álomépítményükhöz, akkor egy idő után a építmény könnyen tákolmány-szerűvé válik. Egy idő után senki sem fog emlékezni, mi volt az eredeti részek célja.

Mi, tanácsadók, szeretünk a dobozban maradni. Nem azért vagyunk szupergyorsak, mert úgy edzünk és táplálkozunk, mint Usain Bolt, hanem mert elég sok LEGO-darabot ismerünk ahhoz, hogy pikk-pakk megoldjuk az összetettebb problémákat is.

Még az ügyfeleink is elámulnak azon, hogy akár heteken belül találunk működő megoldást a problémáikra. Kicsiben kezdjük: egy párfős csapattal és egy jól meghatározott problémával. Aztán amikor a teljes csapat elkezdi használni az új megoldásokat, általában még többet kérnek belőle, vagy más csapatoknak hencegnek arról, milyen termékenyek lettek az új tulajdonságoknak köszönhetően.

Viszont amikor nem létezik az a darab, amelyre szükségünk lenne, akkor okosnak kell lennünk. Túl sok idő és túl nagy kockázat létrehozni és fenntartani egy személyre szabott tulajdonságot. Ha ebben az iparágban vagy, tudod, miről beszélek. Ebben az esetben meg kell kérdeznünk, hogy pontosan mi az, ami hiányzik a dobozból.

…vagy gondolkozhatsz a dobozon kívül

Itt húzzuk meg a határvonalat a tanácsadók és a terjesztők között. Atlassian terjesztőként a dobozon kívül kell gondolkoznunk. Előfordul, hogy a doboztól mégtávolabb. Amikor  a felhasználóinkkal beszélgetünk, vagy egyszerűen egy Atlassian terméket használunk, akkor a hiányzó elemek mintáit keressük, vagy megnézzük, hogy az ügyfelek hol használnak kerülő megoldásokat. Az UX területén ez egyértelmű jele annak, hogy a területen bőven van mit fejleszteni.

Terjesztőként néha úgy kell gondolkoznunk, mintha nem is lenne doboz. Ha nem ismerjük a dobozt, máshogy gondolkozunk. Pont úgy, mint azok a felhasználók, akik nem rendelkeznek technikai tudással, de pontosan tudják, hogy valami hiányzik nekik. Ezért használnak kerülő megoldásokat.

Ezért gondolkozunk úgy, mint az ügyfeleink. Egy dolog, amit termékfejlesztőként  más területeken megtanultam az elmúlt években, az, hogy az ügyfélvisszajelzések aranyat érnek. De csak akkor, ha okosan használjuk őket. A felhasználók nézőpontja sokszor azért torzított, mert hiányosak az ismereteik a termékről, stresszhatás éri őket, vagy a valóságtól eltérően ítélik meg munkájuk fontosságát. Ez az a trükkös rész, ahol sok terjesztő elvérzik. Kristálytisztán kell tudnunk, mi hiányzik a LEGO-dobozból, ha meg akarjuk építeni az építményünket, és kifényesíteni, mint egy gyémántot.

A kis dolgokból lesznek a nagyok 

Atlassian tanácsadóként úgy gondoljuk, hogy az Atlassian termékek a meglévő megoldásokkal is óriási lehetőségeket rejtenek. Így válnak a tulajdonság-gazdag eszközök sokoldalúvá. Ami még ennél is fontosabb: ezekből a kis dolgokból lesznek azok a nagy dolgok, amelyek pontosan kielégítik a felhasználók mindennapi vagy speciális igényeit. /en/2017/04/25/Atlassian:+It's+Like+Playing+with+LEGO

A különbség aközött, hogy egy vagy két Atlassian alkalmazást használnunk nagyon nem csak abban nyilvánul meg, hogy második alkalmazás funkciókészlete is rendelkezésünkre áll. Az egyik legjelentősebb ereje az Atlassian ökoszisztémának a különféle integrációs megoldások. Ez az írás megpróbálja összefoglalni a legfontosabbakat a HipChat szemszögéből.

Az integrációt megelőzően

Eldöntendő, hogy globális vagy szoba alapú integrációt szeretnénk megvalósítani. A globális integráció minden szobára érvényes, a szoba szintű csak arra a szobára, melyben telepítésre kerül.

  • Globális integráció telepítése a Group admin > Integrations részben lehetséges. Itt a Find New oldalon a már meglévő integrációk is áttekinthetőek.
  • Szoba szintű integrációt a Group admin > Rooms > Integrations menü alatt hozhatunk létre.
EszközIntegrációs lehetőségekKonfigurációs segédlet
JIRA Core
  • HipChat szobába értesítések érkezhetnek egy feladattal kapcsolatban
    • Létrehozáskor
    • A felelős megváltozásakor
    • Megjegyzés írásakor
    • Egy állapotátmenetet követően
  • Lehetőség van a JIRA-ban egy feladathoz kapcsolódó egyeztetések számára dedikált HipChat szoba létrehozására
  • JIRA feladatok, és Service Desk kérések előnézeti módban megtekinthetőek a HipChat szobában, ha valaki megemlíti őket

 

A JIRA és HipChat integráció a JIRA 6.4 és későbbi verziókban már elérhető. Korábbi verziók esetében vagy a legfrissebb integrációs plugin letöltéséhez a HipChat for JIRA segédlet nyújt támogatást.

Első lépésként bizonyosodjunk meg arról, hogy a JIRA és a HipChat szerver ugyanazon tűzfal mögött található (az integráció használja mind a pull, mind a push irányokat). A kapcsolati státusz a két alkalmazás között ellenőrizhető (Összekapcsolt, Korlátozott, Nincs kapcsolat, Ismeretlen)

Ezt követően a JIRA és a HipChat az alábbi lépések segítségével integrálható

 

  1. Lépjünk be JIRA vagy Projekt Adminisztrátorként
  2. JIRA administration console > Applications
  3. Integration részben válasszuk a HipChat-et
  4. Válasszuk a linket a Connect HipChat alatt
  5. Kövessük az instrukciókat a JIRA és a HipChat összekötéséhez
  6. Ha készen állunk akkor összeköthetőek a JIRA projektek HipChat szobákkal

JIRA projektek összeköthetőek egy vagy több HipChat szobával, így amikor egy feladat frissül, létrejön, értesítést kaphatunk a HipChat szobába.

  1. Lépjünk be JIRA vagy Projekt Adminisztrátorként
  2. Adminisztráció > Projektek részben
  3. Válasszuk a Projekteket
  4. A Projekt Adminisztráció részben a HipChat Integration opciót
  5. Válasszuk ki a megfelelő HipChat szobát, és kattintsunk a Hozzáad gombra
  6. Adjuk meg a feladat típusát, prioritását, vagy válasszuk a Haladó szekciót ahol JQL feltételt is megadhatunk 
  7. Adjuk meg az eseményeket, melyek hatására értesítéseket szeretnénk kapni (feladat létrehozása, felelős módosítása, új megjegyzés, állapotátmenetek)
  8. WEB és IOS kliensek esetében lehetőség van a felhasználók figyelmeztetésére is (hangjelzéssel, felugró ablakokkal,  flugró ikonnal).
  9. A változtatások automatikusan elmentésre kerülnek

Privát szobák

Meghívás alapú privát szobák esetében szükség van egy extra engedélyezésre a HipChat integrációs felületen. Amikor ez az extra autorizációs fázis megtörtént, akkor látszanak az olyan privát szobák a legördülőben, melynek az aktuális felhasználó tagja.Ha az integrációs megvalósult, akkor mindenki, aki a szoba tagja látni fogja az értesítéseket.

Ezen felül az alábbi beállítási lehetőségek végezhetőek el:

  • Előnézeti mód engedélyezése minden projektben
    • Ez a beállítás a Projet Adminisztráció részben felülbírálható
  • Előnézeti mód engeélyezése a vendég szobák számára

 

JIRA SoftwareHasonló funkcionalitás érhető el, mint JIRA Core esetében

Nem igényel JIRA Software specifikus beállításokat

Planning Poker (https://www.planningpoker.com/) for HipChat egy hamarosan kiadásra kerülő addon, mely nagyon izgalmas lehet agilis csapatok számára.

JIRA Service DeskHasonló funkcionalitás érhető el, mint JIRA Core esetébenNem igényel Service Desk specifikus beállításokat.
Confluence
  • Munkaterület - Szoba szintű lehetőségek tekintetében értesítést kaphat egy szoba, ha
    • Egy oldal létrejön
    • Egy blogbejegyzés létrejön
  • Ki érhető el
    • Amennyiben egy felhasználó linkké alakított neve vagy megemlítésése fölé húzzuk az egeret megtudhatjuk, hogy elérhető-e HipChaten. A zöld, sárga és piros ikonok jelzik, hogy elérhető, távol van, vagy épp azt szeretné, hogy ne zavarják.
  • Első lépésként kössük össze a HipChat-et a Confluence-vel
    • Ehhez adminisztrátor joggal kell rendelkeznünk HipChat oldalon is
    • Confluence adminisztrátorként az Adminisztráció > General Configuration > HipChat Integration szekcióban kattintsunk a Connect HipChat linkre.
    • Munkaterület adminisztrátorként a Space Tools > Integration > HipChat a beállítások helye
      • Amennyiben a munkaterület a Documentation theme-t használja, akkor Browse > Space Admin > HipChat
    • Eközben a HipChatben Csoport Adminisztrátorként bejelentkezve kell lennünk
  • Munkaterület Adminisztrátor jogosultság szükséges az integrációhoz, valamint ha privát szobával szeretnénk integrálni a munkaterületet be kell jelentkeznünk a HipChat-be az integrációs felületen is.
  • A kapcsolat kiépítése után az értesítések beállítására a Space Tools > Integration > HipChat részben van lehetőség a kiválasztott szoba hozzáadásával
Bamboo

Az alábbi esetekben érkezhetnek értesítések a Bamboo felől egy szobába:

  • amikor egy build sikeresen vegződik vagy hibára fut
  • amikor a build felelősét kell értesíteni
  • amikor a korábban hibára futott build javítása sikeres volt
  • amikor a build egy kézi indítású lépését el kell indítani
  • amikor a Bamboo az automatizált telepítést elkezdi vagy befejezi

...és számos egyéb esemény hatására is.

A Bambbo értesítések beállításhoz az alábbi lépésekre van szükség:

  1. Adjuk meg a hipchat.api.url rendszer változóban a HipChat szerver elérhetőségét
  2. Állítsuk be az értesítéseket a Bambooban HipChat "Recipient type" segítségével
Bitbucket Server

A HipChat - Bitbucket Server integráció segítségével az alábbi események hatására kaphatunk értesítéseket a szobákban:

  • Pull requesteket
    • létrehozunk
    • megjegyzéssel látunk el
    • összefésülünk (merge)
    • visszautasítunki (decline)
  • Commitokat
    • végrehajtunk (push)
    • megjegyzéssel látunk el
  • A beállításokhoz válasszuk az Administration Settings > HipChat integration
  • Alul a Connect HipChat gombot megnyomva, adjuk meg a HipChat URL-jét, majd kattintsunk a Connect HipChat-re.
  • Jelentkezzünk be egy olyan HipChat felhasználóval, melynek adminisztrátor jogai vannak. 
  • Kattintsunk az Install-ra, mellyel befejezzük a telepítést.
  • Válasszuk ki a repository-t melyből az értesítéseket küldeni akarjuk, és a HipChat szobát, ahová az értesítések érkezzenek.
    • Akár több szoba is megadható, de ezeket egyesével kell felvenni. 
    • Ismételjük meg ezt a lépéssorozatot minden repository-nál, melyekről értesítéseket szeretnénk kapni.
Bitbucket Cloud

Bitbucket az alábbi esetekben tud értesítéseket küldeni egy HipChat szobába

  • Pull Requesteket
    • létrehozunk
    • megjegyzéssel látunk el
    • összefésülünk (merge)
    • visszautasítunk (decline)
  • Commitokat
    • végrehajtunk (push)
    • megjegyzéssel látunk el
  • Feladatokat
    • létrehozunk
    • módosítunk
    • megjegyzéssel látunk el
  • Bitbucket és HipChat integráció megvalósításához az alábbiak szükségesek:
    • HipChat hozzáférés ahhoz a szobához, ahol az értesítéseket szeretnénk megkapni
    • Bitbucket hozzáérés, mely rendelkezik az alábbiak egyikével
      • Egyéni hozzáférés: a repository tulajdonosának kell lennie nem elegendő az adminisztrátor jogosultság
      • Csapat hozzáférés: adminisztrátori hozzáférés szükséges a csapathoz ami a tulajdonosa a repository-nak , mellyel kapcsolatban az értesítéseket be akarjuk állítani.
  • Lehetséges integrációk
    • Csapat számára az integráció beállítására a Select Teams szekcióban a csapat nevének kiválasztását követően a Manage team részben van lehetőség, vagy a repository beállításokban.
    • Egyéni hozzáférés esetén az integráció a repository beállításokban valósítható meg.
    • Amennyiben midn csapat, mind egyéni hozzáféréssel rendelkezünk ne feledjük el beállítani mindkét esetben az integrációt
  • Az integráció lépései
    • Kattintsunk a HipChat integrációra
    • Majd az Install integration részen kövessük az instrukciókat
    • Válasszuk ki a repositoryt melyből az értesítéseket szeretnénk küldeni és a HipChat szobát, ahová ezek érkezzenek
      • Több szoba is kiválasztható, ahová az értesítések érkezzenek, de ezeket egyesével szükséges beállítani
      • Ismételjük meg ezeket a lépéseket az összes olyan repository-val, melyekről értesítést szeretnénk küldeni
    • Adjuk meg a kívánt értesítéseket

/en/2016/05/09/Integration+opportunities+-+The+real+power+of+Atlassian

JIRA Migráció

Ez a cikk egy olyan sorozat része, amelyet ügyfeleinknél végrehajtott projektek tapasztalataiból merítünk.

Egyik ügyfelünk (egy nagy európai logisztikai cég Magyarországi leányvállalata) több európai irodával van napi munkakapcsolatba. Az anyacégben cégben több JIRA rendszert is üzemeltetnek, de eltökélt szándékuk, hogy ezeket összevonják egy központi JIRA-ba.

Ennek a folyamatnak a részeként bíztak meg minket, hogy migráljunk egy francia JIRA rendszerből projekteket a központi JIRA-ba, amelyet ők üzemeltetnek. Azonnal látszott, hogy eljött az idő a Project Restore funkciójának éles bevetésére.

A helyzetet bonyolította, hogy a migrálandó JIRA egy JIRA Cloud volt, tehát először egy köztes JIRA rendszerbe történő áttöltés végrehajtása vált szükségessé. Ezt a folyamatot hamarosan egy külön posztban részletezzük.

Migrálási lehetőségek

Mivel a cél JIRA már éles használatban volt, nem volt lehetséges  migrálandó JIRA rendszer teljes betöltése, habár ez lett volna a legegyszerűbb megoldás.

Egyértelmű volt, hogy a JIRA Project Restore funkcióját kell alkalmaznunk. Ha valaki megnézi ennek leírását, azonnal láthatja, hogy mennyire bonyolult tud lenni egy ilyen migráció ha sok projektet minden összetevőjével együtt kell átmozgatni. A dokumentáció szerint nagyon sok manuális munkával létre kell hozni minden elemet, sémát, mezőt stb az adatok áttöltése előtt.

A sok projekt és az addonokkal átszőtt workflowk, egyedi mezők több napnyi munkával kecsegtettek. Ezért keresni kezdtünk egy könnyebb utat, valamilyen megoldást, amely segítségünkre lehet, és végül megtaláltuk a Project Configurator nevű add-ont, amely nagyon hasznosnak bizonyult.

A migrálás lépései

Néhány próbálkozás után az alábbi lépések vezettek eredményre. Ezek a lépések feltételezik, hogy a forrás és cél JIRA ugyanolyan verziójú. Ha nem, frissítésekkel el kell érni ezt, ezzel is csökkentve az adatok betöltésének hibalehetőségeit.

Step 1 - Emailezés kikapcsolása a cél JIRA-ban

Mielőtt belefognánk a migrálásba, érdemes kikapcsolni az emailek fogadását és küldését a JIRA-ban. Ezt a legbiztonságosabban a setenv.sh/bat file-ban lehet megtenni, újraindítás szükséges lesz:

-Datlassian.mail.senddisabled=true
-Datlassian.mail.fetchdisabled=true
-Datlassian.mail.popdisabled=true

Step 2 - Add-onok

Ha a forrás JIRA-ban vannak olyan add-onok, amelyek a cél JIRA-ban nincsenek, vagy más a verziójuk, akkor telepíteni esetleg frissíteni kell őket a célrendszerben, mivel az átmozgatott metaadatok (pl workflow komponensek, egyedi mezők, stb) tartalmazhatnak elemeket ezekből az add-onokból. Ezért kritikus, hogy ezek a bővítmények elérhetők legyenek a migráláskor.

Fontos tudni, hogy a teljes export-importtal ellentétben a projektek migrálása nem fogja magával hozni a pluginek konfigurációs adatait. Ezeket kézzel kell reprodukálnunk a célrendszerben a migrálás előtt.

Step 3 - Metaadatok átmozgatása Project Configurator segítségével

Ez az add-on nagyon hasznosnak bizonyult, rengeteg időt, erőfeszítést megspórolt számunkra, de van néhány fontos dolog, amit tudni kell.

Az add-on használatának lépései:

Névütközések feloldása

A forrás és célrendszerben lehetnek azonos nevű elemek (jellemzően a Default sémák), amelyek beállításai különböznek. Ez nem jelent problémát a Project Configurator számára, mivel egyszerűen felülírja a célrendszer azonos nevű elemeit.

Ezt el kell kerülni, így a névütközéseket átnevezésekkel célszerű feloldani. Már a forrás rendszerben érdemes átnevezni minden érintett dashboardot, szűrőt, sémát, workflowt, egyedi mezőt.

Metaadatok exportálása

A Project Configurator adminisztrációs oldaláról lehet indítani:

ennek eredménye egy XML file lesz.

Adatok beöltése a célrendszerben

Betöltés előtt fontos, hogy legalább ezt az egy oldal elolvassuk és megértsük a Project Configurator dokumentációjábanhttps://awnaba.atlassian.net/wiki/x/KIAF

A Project Configurator lehetővé teszi adatok betöltését szimulációs üzemmódban. Ennek lényege, hogy minden módosítást egy tranzakcióban hajt végre, amelyet a betöltés végén visszaállít (rollback).

Fontos, hogy először szimulációval töltsük be az adatokat.

Ha hiba nélkül lement a szimuláció, indíthatjuk az éles betöltést az "Apply changes?" opció bekapcsolásával.

 

Fontos tudnivalók

Projekt komponensen és verziók:

  • A Project Configurator alapértelmezés szerint betölti az egyes projektek komponenseit és verzióit is. Azonban a betöltéskor megadhatjuk, hogy ezeket hagyja figyelmen kívül. Azért hasznos kihagyni a komponenseket és verziókat, mert a projekt adatainak betöltésekor (ld lejjebb), a JIRA félbeszakítja a betöltést, mivel a projektben már vannak verziók és komponensek. Folytatás előtt pedig ki kell majd törölni ezeket a projektekből. Emiatt hasznos már be sem tölteni őket.

Project Configurator a felhasználókat is átviszi, de fontos tudni:

  • Új jelszavak kerülnek létrehozásra, a felhasználóknak első bejelentkezéskor a jelszóemlékeztetőt kell használni a login képernyőn.
  • A felhasználók az első írható user directoryban jönnek létre, így a user directory-k sorrendjének beállítása migrálás előtt fontos lehet a célrendszerben.

 

Step 4 - Workflow-k átvitele

A Project Configurator legutóbbi verziója már támogatja a workflowkat, mi még a JIRA Workflow export/import funkcióját használtuk. Ez egy nagyon okos lehetőség, mert a workflow bundle magával viszi a workflow függőségeit is: transition view képernyőket, egyedi mezőket, állapotokat, add-onokból származő összetevőket (pl post-functionok). Ezért is fontos, hogy a célrendszerben az ad-onok elérhetőek legyenek a kiinduló JIRA-val azonos beállításokkal.

Az export részletes visszajelzést ad, az import pedig lehetővé teszi, hogy finomhangoljuk a betöltendő folyamatot. A Workflow export/import dokumentációja tartalmazza a részleteket.

 

Step 5 - Adatok betöltése

A Projektek áttöltéséhez teljes XML exportot kell végrehajtani a forrásrendszerben, majd a cél JIRA-ban a "Project Import" művelettel kell kezdeményezni a projektek egyesével való betöltését.

A projekt betöltésekor részletes jelentést kapunk a sikerességről és esetleges hibákról, amelyek javítása után megismételhető a betöltés.

 

Fontos

A Project restore funckó használatakor azt tapasztaltuk, hogy az egyes issue-k betöltésekor a Create tranzíció az érintett workflowban lefut, ellentétben a teljes XML export és import művelettel. Ezt fontos megjegyezni.

Emiatt ha a Create tranzíció olyan post-functionöket tartalmaz, amelyek inicializálják az issuet, akkor a végeredményként létrejövő betöltött issue-k különbözhetnek a forrásrendszerbeli párjuktól.

Például: ha egy post-function a Create tranzícióban beállítja a felelős személyt (Assignee), akkor pl a létrejövő issue más személyhez lesz rendelve, mint a forrásrendszerben. A MISC Workflow Extensions add-onnak vannak ilyen post-functionjei.

Az ilyen problémákat elkerülendő érdemes átnézni a migrálandó workflowkat, és az áttöltés előtt kivenni belőlük ezeket a post-funcionöket, mad a migrálás végeztével visszarakni őket.

Ezt legkönnyebben úgy oldhatjuk meg, hogy az érintett workflowkat lemásoljuk, majd a veszélyes post-funcionöket kivesszük az eredetiből. Migrálás után a másolat workflow-ra kicseréljük a módosítottakat az érintett workflow sémákban.

Step 6 - Mail Handlerek

Ha a forrásrendszerben voltak Mail Handlerek, ezeket fel kell venni az új JIRA-ban is, azonos tartalommal: Administration / System / Incoming Mail

Step 7 - Emailezés visszakapcsolása és újraindítás

Végül a setenv.sh/bat módosításával kapcsoljuk vissza az emailezést, és újraindítjuk, majd újraindexeljük a JIRA-t.

Backup stratégia

Javasolt minden fenti lépés előtt egy backupot készíteni mind a JIRA-ról, mind az adatbázisról. Ezáltal mindig lesz egy visszaállítási pont, ahonnan esetleges hibák után folytathatjuk a folyamatot. Ha virtuális szervereken futnak a rendszerek, akkor a snapshotok készítése egy gyors, kényelmes és megbízható módja a backupnak.

Tanulság

A JIRA bonyolult adatmodellje, a projektek minden aspektusával együtt megnehezíti éles rendszerben történő betöltésüket még akkor is, ha a Project Configurator segítségével jelentősen lecsökken a végrehajtás ideje. Ha azonban figyelmesen, és gondosan járunk el, akkor az időigény a fenti lépések fényében pontosabban tervezhető, és a folyamat gyorsabban vezet majd eredményre. /x/kQBzAg

Migráció Atlassian környezetbe? – Redmine JIRA migráció

A "Migráció Atlassian környezetbe?"  egy cikksorozat, mely egy tipikus ügyfélprojekt témakörét öleli fel: adat és üzleti logika migráció egy adott megoldásból Atlassian környezetbe. A váltás okai, és a forrás rendszerek, melyből a migrációt elvégeztük nagyon különbözőek lehetek, ezért igyekszünk annyi esettanulmányt összegyűjteni, amennyit csak lehetséges. Olvasson tovább, hogy megismerhesse azokat trükköket, tippeket, melyekkel sokkal egyszerűbbé válhat egy-egy migrációs projekt.

A forrás rendszerről

„A Redmine egy flexibilis projekt menedzsment webalkalmazás, melyet Ruby on Rails keretrendszerben írtak. Platform és adatbázis független.”

Szempont

Redmine

Felhasználási terület

Projekt menedzsment

1. kiadott verzió

2006.06.25.

Jelenlegi verzió (kiadás dátuma)

3.2.0 (2015.12.06)

Licence

Open Source, GNU General Public License v2 (GPL)

Költségek 500 felhasználóra

Free

Keretrendszer

Ruby on Rails

Platform

Felhőben és helyben telepített verzióban is elérhető

Weboldal

http://www.redmine.org/

Készítő(k)

Jean-Philippe Lang

Demo oldal

http://demo.redmine.org/

Kiegészítők

http://www.redmine.org/plugins (729 kiegészítő érhető el)

http://www.redmine.org/projects/redmine/wiki/ThirdPartyTools

A váltás okai

Az ügyfelünk már korábban elkezdte használni a Confluence-t belső tudásbázis építésre, és dokumentum tárolásra. Az integráció lehetősége a JIRA és a Confluence között erős ütőkártyának bizonyult, de az igazi okok a rugalmasság és az extra funkciók voltak, melyek a váltással elérhetővé váltak.

A korábbi, Redmine-os megoldást az alábbi szempontok miatt tartották kényelmetlennek:

  • egyre szofisztikáltabb jogosultsági rendszerre volt szükségük
    • mely a JIRA-ban a biztonsági és jogosultsági sémákkal könnyen megvalósítható
  • e-mail kollaborációt szerettek volna megvalósítani a feladatoknál
  • a havi jutalmazási rendszer a lejelentett munkaidő alapján került kiszámításra, ezért egyre komolyabb igényeik merültek fel a munkaidő jelentéssel kapcsolatban

A migráció folyamata

A migráció jelentős része 6 egyszerű lépéssel volt megvalósítható. A JIRA Importers Plugin (vagyis JIM, ahogy gyakran emlegetik) a JIRA Redmine Importer plugin segítségével egy nagyon hatékony megoldás, kifejezetten egyszerű felhasználói felülettel megtámogatva. (Adatbiztonsági okokból néhány kép az alábbiak közül pusztán minta, nem az ügyfél éles rendszerében készültek)

  1. A kapcsolati adatok megadása
  2. Projektek összerendelése
  3. Egyedi mezők beállításai
  4. Mezők beállításai
  5. Értékek összerendelése
  6. Feladatok közötti kapcsolatok megadása

Nehézségek és megoldások

Több projektről egybe

Ügyfelünk rengeteg projektet használt a Redmine rendszerben, de úgy döntött, hogy az összes migrálandó feladatot egyetlen JIRA projektben szeretné kezelni. Szerencsére a migráció során megadható minden egyes forrás projekt esetében, hogy mi legyen a cél projekt, így ez a kérés könnyen megoldható volt.

Letiltott felhasználók

A teszt migráció során a napló információkban az alábbihoz hasonló bejegyzéseket találtunk:

 2015-08-05 10:14:27,489 WARN - Commenter named l***a.o***z not found. Creating issue with currently logged in user instead

Gyors utánajárás után rájöttünk, hogy a figyelmeztetés oka az volt, hogy a felhasználó a Redmine-ben már le volt tiltva. Az export idejére engedélyeztük, mely szerencsére megoldotta a problémát.

A JIM (JIRA Importers Plugin) napló bejegyzések nagyon részletesek, és hasznos információval szolgálnak egy migrációs projekt során, talán ez a termék egyik nagy erőssége (ahogy az alábbi példában látható).

Az első teszt migráció
2015-08-05 12:56:29,826 INFO - Import started by admin using com.atlassian.jira.plugins.importer.redmine.RedmineDataBean
2015-08-05 12:56:29,850 INFO - ------------------------------
2015-08-05 12:56:29,850 INFO - Importing: Users
2015-08-05 12:56:29,850 INFO - ------------------------------
2015-08-05 12:56:29,850 INFO - Only new items will be imported
….
2015-08-05 12:59:00,807 INFO - 48 users associated with import. 47 new users were created and imported as active.
2015-08-05 12:59:00,807 INFO - ------------------------------
2015-08-05 12:59:00,807 INFO - Finished Importing : Users
2015-08-05 12:59:00,807 INFO - ------------------------------
Egy újabb migrációs próbálkozás során, amikor nem töröltük a már létrehozott felhasználókat (pusztán az adatmigráció tesztelésekor)
2015-08-06 16:08:09,563 INFO - Import started by admin using com.atlassian.jira.plugins.importer.redmine.RedmineDataBean
2015-08-06 16:08:09,573 INFO - ------------------------------
2015-08-06 16:08:09,573 INFO - Importing: Users
2015-08-06 16:08:09,573 INFO - ------------------------------
2015-08-06 16:08:09,573 INFO - Only new items will be imported
2015-08-06 16:09:54,264 INFO - 48 users associated with import. 0 new users were created and imported as active.
2015-08-06 16:09:54,264 INFO - ------------------------------
2015-08-06 16:09:54,264 INFO - Finished Importing : Users
2015-08-06 16:09:54,264 INFO - ------------------------------

Hiba a többszörös felhasználó választó mező migrálásakor

Volt egy többszörös felhasználó választó mező a Redmine rendszerben, melyet "Résztvevők"-nek neveztek el. Sajnos a migráció során felhasználói nevek vagy azonosítók helyett azonosíthatatlan számsorozatok kerültek a mezőbe. Bejelentettük a hibát az Atlassian felé, akik viszont sajnos nem tudták ezt reprodukálni. Az ügyfelünk viszont - biztonsági szabályok miatt - nem engedélyezte a távoli belépést az Atlassian részére, így nem sikerült megoldani ezt a problémát. A fentiek fényében nem maradt más hátra, mint a migrációt követően kézzel pótolni ezeket a hiányosságokat.

Redmine és kiegészítők frissítése

Ahogy a dokumentációban is olvashatjuk, nagyon fontos a megfelelő verzió számok ellenőrzése mind a Redmine, mind a JIRA migrációs kiegészítők tekintetében. 

  • Bizonyosodjon meg arról, hogy a Redmine legalább 1.3.0+ vagy 2.0+. verzióval rendelkezik.
  • Bizonyosodjon meg arról, hogy legalább az 5.0.2-es JIRA Importers Plugin van telepítve
  • Engedélyezze a REST web szolgáltatásokat a Redmine Administration > Settings > Authentication > Enable REST webservice beállításával

Első alkalommal mi elfelejtettük, és tanúsíthatjuk, hogy tényleg nem működött, kénytelenek voltunk frissíteni a Redmine-t még a végső lekapcsolás előtt (smile)

Tanulságok

  • Nagyon hasznos napló információk - a hibakeresés sokkal egyszerűbb a naplóbejegyzések elolvasása után
  • Az adatok többsége egyszerű lépésről-lépésre követhető megoldás segítségével migrálható, így nem kell tartani a feladattól
  • Nem csak Redmine-ből ilyen könnyű migrálni, (Trac, Rally, Asana, Bugzilla, …), érdemes a lehetőségeket áttekinteni

További részletek

Amennyiben további részletek iránt érdeklődik, az alábbi rövid előadás keretében megismerheti a projektet. A felvétel a 2. Magyar Atlassian Meetupon készült.

/pages/viewpage.action?pageId=40730668

Ultimate Permission Manager has been acquired

Atlassian has acquired the Ultimate Permissions Manager app. For more details, please see the Atlassian blog post and META-INF blog post

Effective May 3, 2019, this app has been removed from the Marketplace and is no longer available for purchase or maintenance renewal. In accordance with Atlassian's End of Life policy, the Ultimate Permissions Manager app will have support for two years, with an end of life date of May 3, 2021. While the app is supported, please raise issues with Atlassian directly via support.atlassian.com.

A "Tényleg jól ismeri a Confluence jogosultsági rendszerét?" egy cikksorozat, mely a Confluence jogosultsági rendszerének kevésbé ismert, nem triviális, vagy akár meghökkentő aspektusaira fókuszál. Olvasson tovább, hogy megismerje mindazt, amit felfedeztünk a részletek felkutatásához bejárt izgalmas utazásunk során.

Némi háttér információ

Jogosan merül fel a kérdés, hogy mi az olyan érdekes a Confluence jogosultsági rendszerében, szépen ledokumentált, néhány pipa a felhasználókhoz, a csoportokhoz, és már készen is vagyunk. Ennek ellenére mi azt tapasztaltuk, hogy ez az állítás messze van a valóságtól.

A Confluence jogosultsági rendszerének nemcsak több szintje van (globális, munkaterület, oldal), de ezeknek még egymásra hatása is jelentős, ugyanis előfordulhat, hogy egy jogosultság beállítása vagy hiánya hatással van egy másik jogosultságra, melyek eredményeképpen létrejövő valós (effektív) jogosultságok felderítése gyakran nehézkessé válik.

Más szóval, a valós (effektív) jogosultságok néha a felhasználóknak kiosztott különálló jogosultságok implicit kombinációiként jönnek létre, de előfordul, hogy effektíven olyan jogosultság birtokába jut egy-egy felhasználó, mely közvetlenül nem is feltétlenül lett beállítáva.

A (valós) jogosultságok és oldal korlátozások komplexitása, melyek a tucatnyi, vagy akár több száz munkaterületen, oldalon, átívelve olyan véletlen hozzáféréseket okozhatnak felhasználók, vagy csoportok számára, melyek információ szivárgás kockázatát rejtik magukban. Ez csak egy példa arra, hogy miért kiemelten fontos a Confluence jogosultsági rendszer alapos ismerete egy közepes vagy nagy installáció üzemeltetése, bevezetése során.

Ebben cikksorozatban feltárunk néhány rejtett titkot a Confluence jogosultsági rendszeréből, és megmutatjuk azt is hogyan lehet mégis kézben tartani a jogok kiosztását. Kezdjünk is hozzá!

Információszivárgás a szervezetben

Egy Confluence rendben tartásához három dolog kell: megtartani a titkos információkat, megtartani a titkos információkat, és végül megtartani a titkos információkat... de néha mégis kiszivárog valami.

A Wikipedia szerint: Akkor beszélünk információszivárgásról, ha egy rendszerből jogosulatlan személyek mégis hozzáférhetnek bizonyos zártnak szánt információkhoz.

Vajon ez a szervezetek egy általános problémája? Úgy véljük igen. Nézzünk néhány példát:

  • rákeresve a Google-ban az information leakage policy kifejezésre rengeteg találatot kapunk: ~ 7.760.000 oldal
    • csak mókás összehasonlítás kedvéért az Atlassian szóra keresve ~ 9.330.000 oldal szerepel a találatok között
  • számtalan cikket találunk az interneten nagy adatvesztésekről és a történelem ismert információszivárgással kapcsolatos eseteiről
    • ahogy ezt a szép infografikát böngészve láthatjuk még egészen nagy cégeknek (mint pl. British Airways, Mozilla, NASDAQ, AT&T...) is szembe kellett nézniük ezzel a problémával
  • 51%-a az alkalmazottaknak azt gondolja, hogy a céges információvagyon védelme nem az ő feladatuk, hanem az IT részlegé tudhatjuk meg a Symantec felméréséből
  • Mik az okai az információszivárgásnak, adatvesztésnek? 42%-ban olyan hibák vagy véletlen események, melyeket az alkalmazottak követtek el - látható a prot-on.com vizualizációjában.


Ügyfeleink gyakran kérnek tőlünk egyfajta állapotfelmérés jellegű szolgáltatást Atlassian szoftvereikkel kapcsolatban. Ezen együttműködések során találtunk néhány, bár egyszerűnek tűnő, de könnyen információszivárgáshoz vezető esetet. Ez a cikk négy olyan hasznos tippet foglal össze, amelyek segítségével a Confluence és munkaterület adminisztrátorok elkerülhetik az ebből adódó kellemetlen helyzeteket.

Egy új felhasználónak adódhatnak jogosultságai az alapértelmezett csoportok miatt

"A confluence-users az az alapértelmezett csoport, melybe minden újonnan létrehozott felhasználó bekerül. Minden olyan jogot létrehozáskor automatikusan megkapnak az új felhasználók, amelyek ehhez a csoporthoz hozzá vannak rendelve" - olvashatjuk a Confluence dokumentációjában a csoportokról szóló részben.

E miatt legyünk nagyon óvatosak, amikor pl. egy olyan együttműködő partner számára hozunk létre egy felhasználót, aki nem tagja szervezetünknek (pl. külső cég alkalmazottja). Vélhetően neki nem kellene rendelkeznie a confluence-users csoport tagsággal, ugyanis ez eredményezhet "nem várt" hozzáféréseket belső kollegák számára szánt tartalmakhoz.

Ne feledjük

Minden felhasználónak, aki be szeretne lépni a Confluence rendszerbe rendelkeznie kell a Can Use/Használhatja jogosultsággal. Tehát ha egy felhasználó egyetlen csoportnak sem tagja, akkor önálló felhasználóként kell ezt a jogosultságot megadni számára. További részletek ezzel a jogosultsággal kapcsolatban itt található.

Legyünk óvatosan az alapértelmezett munkaterület jogosultságokkal

A Confluence nagyon egyszerűen támogatja, hogy egy újonnan létrehozott munkaterülethez alapértelmezett jogosultságokat rendeljük, mely remekül fel tudja gyorsítani az adminisztrátorok munkáját. Ez a beállítás a Confluence adminisztráció, Munkaterület jogosultságok, Alapértelmezett munkaterület jogosultságok részben érhető el (a dokumentáció itt található).

Alapértelmezés szerint a confluence-users csoportnak az alábbi jogosultságok vannak beállítva, melyek kiegészíthetőek, testre szabhatóak tetszőleges egyéb csoport jogosultságával:

A legtöbb esetben nem csak a Confluence adminisztrátorok, hanem projektvezetők, üzletág vezetők is jogosultak munkaterületek létrehozására a Confluence rendszeren belül. Ezzel csökkenthető az IT terheltsége, és felgyorsulhatnak az üzleti igények teljesítését célzó folyamatok, így aztán nagyon szeretjük ezt a funkciót. Nem szabad viszont elfeledni, alaposan átgondolni egy újonnan létrehozott munkaterület láthatóságának kérdéseit. Amennyiben egy nagyon érzékeny információknak szánt munkaterületet tervezünk létrehozni - és egyébként a legtöbb esetben amúgy ideális, megengedő alapértelmezett munkaterület jogosultsági beállításokat használjuk - akkor a legbiztosabb megoldás, ha a létrehozást követően kitörlünk minden létrejött jogosultságot, és egyesével kizárólag a legszükségesebb csoportokat, személyeket vesszük fel.

Amennyiben a szervezetben jellemzőek a különösen szenzitív adatok, akkor azt javasoljuk, hogy töröljön ki mindent, még a confluence-users csoportot is az alapértelmezett munkaterület jogosultság beállítások közül. Ezzel elkerülhető a létrehozáskor elfelejtett alapértelmezett jogokból adódó információszivárgás.

A globális beállításokban letiltható a bejelentkezés nélküli hozzáférés

A Confluence kiválóan alkalmas publikus tudásbázisok létrehozására is, ezért van egy olyan beállítási lehetőség, melynek segítségével egy adott tartalmat bárki elolvashat anélkül, hogy be kellene jelentkeznie a rendszerbe. Amennyiben viszont pl. a céges szabályzatok egyáltalán nem tesznek lehetővé  belépés nélküli hozzáférést a tartalmakhoz, akkor a globális beállítások között érdemes kikapcsolni az Anonymous Can Use/Használhatja jogát, ahogy az alábbi ábrán láthatjuk:

Ez a beállítás megvédi a Confluence-ben a véletlen, bejelentkezés nélküli hozzáférésektől, ugyanis ha nincs az Anonymousnak Can Use/Használhatja globális joga, akkor garantáltan nem érhető el semmilyen tartalom az Anonymous (be nem lépett felhasználók) számára, akkor se, ha a Confluence vagy munkaterület adminisztrátor erre jogot adott (akár véletlenül akár szándékosan) bármely munkaterületen.

Mindig ellenőrizzük egy csoport jogosultságát mielőtt egy új felhasználót adunk hozzá

A csoportok - mint mindenhol - jelentősen felgyorsíthatják, és átláthatóbbá tehetik a jogosultsági beállítások menedzsmentjét. Az érem másik oldala viszont, hogy mindig érdemes alaposan ellenőrizni egy csoport jogosultságát új felhasználó hozzáadása előtt, ugyanis ezzel elkerülhetjük a véletlen adathozzáféréseket. A csoport jogosultságok ellenőrzése alapértelmezetten nem egyszerű egy Confluence rendszerben, mert sajnos egyesével végig kell menni az összes munkaterület jogosultsági beállítások szekcióján, de van egy kiegészítő az Atlassian Marketplace-n melynek segítségével ez sokkal egyszerűbb.

Tanulság

A Confluence-t információ megosztására és kollaboráció támogatására tervezték

  • ne feledjük, hogy az új felhasználók kaphatnak létrehozáskor automatikusan jogosultságokat az alapértelmezett csoportok miatt
  • az érzékeny adatokat tartalmazó oldalak, munkaterületek jogosultság beállításainál legyünk nagyon óvatosak, legtöbbször az alapértelmezett beállítások nem alkalmasak
  • amennyiben a céges szabályok nem engedik a bejelentkezés nélküli (Anonymous) hozzáférést, akkor a globális beállításokban tiltsuk le azt
  • mindig ellenőrizzük le kétszer egy csoport jogosultságait, mielőtt új felhasználót adunk hozzá, nehogy véletlen adathozzáférés keletkezzen

/pages/viewpage.action?pageId=38897009A META-INF Kft. az Ultimate Permission Manager for Confluence gyártója.

Ultimate Permission Manager has been acquired

Atlassian has acquired the Ultimate Permissions Manager app. For more details, please see the Atlassian blog post and META-INF blog post

Effective May 3, 2019, this app has been removed from the Marketplace and is no longer available for purchase or maintenance renewal. In accordance with Atlassian's End of Life policy, the Ultimate Permissions Manager app will have support for two years, with an end of life date of May 3, 2021. While the app is supported, please raise issues with Atlassian directly via support.atlassian.com.

Egy régi ügyfelünk (Morphologic Localisation Kft), akinek évekkel ezelőtt fejlesztettünk JIRA addont a JIRA és egy legacy rendszer integrálása céljából, megkeresett minket, hogy segítsünk az általuk használt Confluence rendszer frissítésében. Az első kérdés, amit minden expert ilyenkor feltesz: milyen verziót használnak most.

A válasz meglepő volt: Confluence 2.9. Izgatottak lettünk erre a hírre, mert elképzeltük, mennyi előre nem látható problémát kell majd megoldanunk. Az utolsó alkalom, amikor egy hasonlóan régi Confluence-t láttunk, 2008-ban volt, amikor bevezettük a SonyMusicnál Münchenben.

Az ügyfél maga olyan volt, amit minden tanácsadónak csak kívánni lehet. Elérhetők voltak, megértők, és nagyon  könnyű volt velük dolgozni. Nem is találkoztunk személyesen, csak beszéltünk, cseteltünk, de a bizalom az első perctől megvolt mindkét irányban. Ráfordítás alapú munkát javasoltunk, de megértőek voltak a helyzet bizonytalanságát illetően és elfogadták az érveinket. Jó kezdés után a projekt sikerre volt ítélve.

Nagyon is élő dinoszaurusz

Az  első dolog, amit érzékeltünk az első bejelentkezés után, hogy az ügyfelünk intenzív használója volt a Confluence-nek éveken át. Komoly tudásbázist és dokumentációt építettek. A másik pedig, hogy a régi kis Confluence 2.9 valószínűtlenül gyors volt. Minden oldal kb 1 ms-en belül megnyílt, mintha csak statikus HTML oldalak lettem volna. Mindez teljesen hihetetlennek tűnt a mai, modern, felhízott rendszerek idején, ideérte a JIRA és Confluence legújabb verzióit.

Érdekes volt látni, hogy a Confluence Download Archive szinte az összes eddigi verziót elérhetővé teszi a 2004(!)-ben kiadott 1.0.3-ig visszamenőleg. Nagyon meglepő volt látni, milyen öreg már a Confluence és hogy mekkora hatalmas változáson ment keresztül az évek során. Az alábbi grafikon a Confluence Standalone ZIP csomag méretének változását mutatja az idő függvényében. Az 1.0.3 19(!) MB-os csomaggal indult, míg a jelenleg utolsó 5.9.4 majdnem 440(!) MB méretű, csaknem 23-szor nagyobb óriás.

 

Az is megdöbbentő volt, hogyan képzelte a korszerű UI-t az Atlassian 2009-ben, amikor a 2.9 megjelent. Annyira egyszerű, tiszta, de öreges, minden szépségtől mentes felületnek tűnt. Mégis emlékszem, hogy mennyire lenyűgözött 2008 tájékán a Confluence "szépsége".

Emlékszem a régi Rich text/Wiki markup szerkesztőjére, minden hibájával, bosszantó nyűgjével együtt. Szerencsére ez is kihalt és az Atlassian egy összehasonlíthatatlanul szebb, jobb szerkesztőt fejlesztett, amelyet örömmel használok most is eme poszt megírásához.

Szerettem volna feltelepíteni a poszt írásához a Confluence 1.0.3-t, találtam is hozzá egy 2005-ös evaluation licencet a MAC-fiókomban, amelyet el is fogadott. Azonban az adatbázis kapcsolat beállítása után hibák tömkelegét dobta, és sikertelenül megállt a telepítés. Így nézett ki az install screen.

Még a Confluence 2.9 is viccesnek tűnt a ma megszokott kinézethez képest:

A frissítés

Már a kezdetektől nyilvánvaló volt, hogy a frissítést nem lehet egyetlen nagy lépésben elvégezni. Ehelyett három lépésben, ahogy a Confluence Frissítési Dokumentáció is javasolja.

Ügyfelünk nem csak frissíteni akarta a Confluence-t, hanem egy teljesen új szerverkörnyezetbe szerette volna áthelyezni, az adatbázist is megváltoztatva mySQL-ről Postgresre. Emiatt nem követtük szó szerint a dokumentációt.

Két adottság könnyítette a frissítés-áthelyezés folyamatát:

  • Nem voltak addonok telepítve, az eredeti Confluence-t önmagában használták
  • Abban a helyzetben voltak, hogy a Confluence-t a frissítés idején csak olvasásra használták. Emiatt nem volt szükség tesztfrissítésre, rögtön az éles rendszert lehetett mozgatni. Ráadásul az eredeti szerverkörnyezet nem volt érintett a változásokban.

Frissítés 3.5.13-as verzióra

Első lépésként egy XML backupot készítettem az éles 2.9-es Confluence-ben. Majd a 3.5 széria utolsó 3.5.13-as verzióját telepítettem egy üres Postgres adatbázisra. Végül ebbe a rendszerbe importáltam be az XML állományt. A Confluence gond nélkül upgradelte az adatokat.

Frissítés 3.5.13-ról 5.0.3-ra

A fenti lépéseket ismételve:

  • XML export 3.5.13-ból
  • 5.0.3 telepítése üres adatbázisba
  • XML állomány importálása

Mivel ez is gond nélkül lement, minden adott volt egy sikeres projekthez.

Frissítés 5.0.3-ról to 5.9.4

Mivel az 5.9.4 már az utolsó verzió volt, ezért az installer segítségével telepítettük a Linux környezetbe. Ezt követően a bevált lépéssoroztatot ismételtük: XML backup és visszatöltés.

Minden rendben ment ezúttal is, de a mellékletek még hiányoztak.

Mellékletek frissítése

A Confluence a mellékleteit a Home könyvtár attachments alkönyvtárában tárolja. A korai verziók azonban teljesen már könyvtárstruktúrát használtak a mellékletek elhelyezésére, mint a Confluence 3 és az utána következők.

A 2.9-ről 3.5.13 verzióra való frissítés közben a mellékletek tárhelyének konverziója nem történt meg. Szerencsére az Atlassian lehetőséget ad a tárhely átrendezésére utólag is. Ehhez be kell hívnunk a következő oldal: CONFLUENCE_BASE_URL/admin/restructureattachments.jsp

A könyvtárak kialakítása másodpercek alatt lezajlott, ezt követően a mellékletek megjelentek a 3.5.13-ban is. A további frissítéskor egyszerűen átmásoltam a könyvtárakat az új Home könyvtár attachments mappájába.

Érdekes, hogy a fenti segédoldal a Confluence 5.0.3-ban is elérhető volt, de az 5.9.4-ben már nem. Emiatt minél előbb javasolt elvégezni az attachmentek átrendezését.

A mellékletek megjelenésével véget ért a frissítés. Azaz, csak majdnem. A munkaterületek logói és a felhasználók avatarjai hiányoztak.

Némi guglizással nem sikerült kideríteni, hol tárolta ezeket a Confluence 2.9, de az eredeti attachmentek között felfedeztünk egy könyvtárat, amelynek a neve "nonspaced" volt. Kiderült, hogy ebben vannak a space logók. Elegendő ezt átmásolni a végső Home/attachments könyvtárba, és a logók újra láthatókká válnak.

A felhasznák avatarjait azonban nem sikerült visszaállítani. Ha valaki tudja, hol tárolja ezek a Confluence, írja meg nekünk.

Frissítés utáni tennivalók

Néhány tennivaló akad egy ilyen frissítés után.

  • A Confluence Mail Archiving system addon kikapcsolt állapotba került a frissítés közben. Emiatt ezt újra kellett engedélyezni és a POP3 email fiókokat újra fel kellett venni a space-ekhez.
  • Meg kell növelni a Confluence által használt Heap méretét. A Confluence 2.9 384MB heappel futott vidáman, az 5.9.4-nek adtunk 1,5GB-t
  • Confluence base url beállítását nem szabad elfelejteni

Végszó

Van pár tanulság, amelyet levonhatunk:

  • Még a nagyon régi Confluence rendszerek is jó eséllyel frissíthetők a legújabb verzióra.
  • Az addonok hiánya jelentősen leegyszerűsíti a folyamatot
  • Space logók és avatarok kezelésére külön oda kell figyelni.

A sokkal erősebb szerver ellenére a Confluence 5.9.4 teljesítménye messze elmaradt a régi 2.9-től. Mégsem szeretnénk többet egy ilyen régi verzióval dolgozni. Confluence hatalmas változáson ment át az elmúlt 12 évben, és a kollaboráció, tudásmenedzsment egyik legjobb termékévé vált a sok-sok funkcióval, kellemes UI-al, integrációs lehetőségeivel. Mindez sokkal hatékonyabb eszközzé teszi az őseivel szemben, és egy remek eszközzé, amellyel egyszerűen jó dolgozni. /display/en/2016/02/08/Death+of+a+dinosaur%3A+upgrading+a+Confluence+2.9+instance

Nagy öröm és büszkeség számunkra a hír, hogy megkaptuk az Atlassian Verified Vendor (Ellenőrzött Atlassian Szállító) minősítést! Tudomásunk szerint mi vagyunk az egyetlen magyar partner, aki elérte ezt a szintet!

"Nagyszerű, gratulálok!" - gondolhatnánk, - "De miért jó ez nekem?"

Több dolog miatt, mint elsőre képzelné! Nézzünk egy gyors összegzést arról, hogy milyen elvárásokat fogalmaz meg az Atlassian minden szállítójával szemben, aki ezt a minősítést szeretné elérni, és mi hogyan teljesítettük.

 

 

Legalább 500 aktív példány, egy saját készítésű termékből, melyet az Atlassian rendszerén keresztül értékesítenek

Ez egy nagyon kemény követelmény. Azt jelenti, hogy a szállítónak széleskörű ügyfélbázisa van, más szóval egy fontos szereplő, és együttműködő partner az Atlassian ökoszisztémában.

Nekünk két ilyen termékünk is van:

Garantált kompatibilitás az Atlassain termékekkel

A szállítónak garantálnia kell, hogy minden - az Atlassian rendszerén keresztül értékesített - terméke 14 napon belül kompatibilis lesz az új Atlassian termék verziókkal.

Garantáljuk, hogy ezt a feltételt, keményen dolgozva, minden alkalommal teljesíteni tudjuk.

Dokumentáció és terméktámogatás

Minden, az Atlassian rendszerén keresztül értékesített termék esetében a szállítónak közzé kell tenni egy URL-t, melyen elérhetőek a termékkel kapcsolatos dokumentációk, és bárki számára lehetőséget biztosít kapcsolatba lépni a fejlesztőkkel új funkciók, igények, hibajavítások, kérések leadása céljából.

A mi dokumentációs rendszerünk és terméktámogatásra fenntartott JIRA-nk az alábbi linkek segítségével érhető el: 

Átlátható SLA és terméktámogatási feltételek

A szállítónak garantálnia kell a világos feltételekkel közzétett terméktámogatási és SLA feltételek teljesülését.

A mi terméktámogatásunk heti 5 napban, minden magyar idő szerinti munkanapon, legalább 8 órában elérhető az Atlassian rendszerén keresztül értékesített termékeinkhez.

JIRA-t használunk az ügyfeleink által bejelentett hibajelzések, funkcióigények áttekinthető nyomon követésére az összes Atlassian rendszerén keresztül értékesített termékünk esetében.

Forduljon hozzánk bizalommal akár csak kérdése merült fel, akár hibát talált termékeink bármelyikében. Figyelünk a beérkező visszajelzésekre!

Kapcsolattartó vészhelyzet esetére

A szállítónak az Atlassian rendelkezésére kell bocsátani egy 7/24-ben elérhető kommunikációs csatornát, melyen keresztül nem több, mint 15 percen belül választ kell adni minden kritikus problémára az Atlassian rendszerén keresztül értékesített termékekkel kapcsolatban.

Egy e-mail és egy telefonos csatornát is létrehoztunk, melyet az Atlassian rendszeresen tesztel is annak érdekében, hogy megbizonyosodjon, ha gond van, 15 percen belül tényleg elér bennünket. Eddig sikerrel álltuk a teszteket (smile)

Hogyan tovább?

Bár ez nem a kezdete, - de egy igen jelentős mérföldköve - egy csodálatos barátságnak (Forrás: Macska-jaj (smile) ) ügyfeleinkkel, melynek keretében olyan professzionalizmust garantálunk számukra, melyben megbízhatnak.

Confluence jogosultságok? Tartalom exportálás? E-mail kollaboráció JIRA-ban? Vagy az JIRA értesítő e-mail-ek számának csökkentése?

Nézzen körbe a termékeink között, talán az egyik épp megoldás a problémádra. /display/en/2016/01/21/We+are+Atlassian+Verified+Vendor+-+Learn+what+benefits+it+comes+with

Ultimate Permission Manager has been acquired

Atlassian has acquired the Ultimate Permissions Manager app. For more details, please see the Atlassian blog post and META-INF blog post

Effective May 3, 2019, this app has been removed from the Marketplace and is no longer available for purchase or maintenance renewal. In accordance with Atlassian's End of Life policy, the Ultimate Permissions Manager app will have support for two years, with an end of life date of May 3, 2021. While the app is supported, please raise issues with Atlassian directly via support.atlassian.com.

A "Tényleg jól ismeri a Confluence jogosultsági rendszerét?" egy cikksorozat, mely a Confluence jogosultsági rendszerének kevésbé ismert, nem triviális, vagy akár meghökkentő aspektusaira fókuszál. Olvasson tovább, hogy megismerje mindazt, amit felfedeztünk a részletek felkutatásához bejárt izgalmas utazásunk során.

Némi háttér információ

Jogosan merül fel a kérdés, hogy mi az olyan érdekes a Confluence jogosultsági rendszerében, szépen ledokumentált, néhány pipa a felhasználókhoz, a csoportokhoz, és már készen is vagyunk. Ennek ellenére mi azt tapasztaltuk, hogy ez az állítás messze van a valóságtól.

A Confluence jogosultsági rendszerének nemcsak több szintje van (globális, munkaterület, oldal), de ezeknek még egymásra hatása is jelentős, ugyanis előfordulhat, hogy egy jogosultság beállítása vagy hiánya hatással van egy másik jogosultságra, melyek eredményeképpen létrejövő valós (effektív) jogosultságok felderítése gyakran nehézkessé válik.

Más szóval, a valós (effektív) jogosultságok néha a felhasználóknak kiosztott különálló jogosultságok implicit kombinációiként jönnek létre, de előfordul, hogy effektíven olyan jogosultság birtokába jut egy-egy felhasználó, mely közvetlenül nem is feltétlenül lett beállítáva.

A (valós) jogosultságok és oldal korlátozások komplexitása, melyek a tucatnyi, vagy akár több száz munkaterületen, oldalon, átívelve olyan véletlen hozzáféréseket okozhatnak felhasználók, vagy csoportok számára, melyek információ szivárgás kockázatát rejtik magukban. Ez csak egy példa arra, hogy miért kiemelten fontos a Confluence jogosultsági rendszer alapos ismerete egy közepes vagy nagy installáció üzemeltetése, bevezetése során.

Ebben cikksorozatban feltárunk néhány rejtett titkot a Confluence jogosultsági rendszeréből, és megmutatjuk azt is hogyan lehet mégis kézben tartani a jogok kiosztását. Kezdjünk is hozzá!

Szituáció

A szituáció gyors összefoglalása:

  • Bence egy felhasználó a Confluence munkaterületeden
  • Bence nem tagja egyetlen felhasználó csoportnak sem (de van globális joga a belépésre, szóval tudja használni a rendszert)
  • Bence a biztonsági csoport tagja, aki az oldal korlátozások menedzseléséért felelős
  • Szóval, a munkaterület adminisztrátora beállította Bencének a "Restriction Add/Delete" jogosultságot (ahogy az ábrán is látszik)

Jónak tűnik, nemde?

Nem igazán... Nem is olyan sokára Bence minden bizonnyal írni fog neked egy levelet, hogy "Szia, Sajnos nem tudom menedzselni az oldal korlátozásokat (lásd a csatolt képernyőképet). Kérlek javítsd"

Mi a rossz a jogosultsági beállításokban? Követtük a legkevesebb jogosultság elvét, beállítottuk, amire szüksége van, Bence mégis egy szomorú felhasználó, aki nem tudja elvégezni a munkáját.

Probléma

Probléma

A felhasználó nem tudja a korlátozásokat menedzselni, annak ellenére, hogy van "Restriction Add/Delete" jogosultsága a munkaterületen.

Megoldás

Megoldás

Ha hiszed, ha nem, Bencének "Page Add" jogosultságra van szüksége!

A "Restrictions Add/Delete" és a "Page Add" jogosultság beállításával, ahogy az ábrán is látható 

Bence megkapja a kívánt jogosultságot, és képes lesz menedzselni a korlátozásokat.

Meglepő? Anno elsőre nekünk is az volt! (smile)

Tanulság

Soha ne felejtsük el a "Page Add" jogosultságot is megadni olyan felhasználónak, aki az oldal korlátozások menedzsmentjét szeretné ellátni.

/pages/viewpage.action?pageId=38895989A META-INF Kft. az Ultimate Permission Manager for Confluence gyártója.

Ultimate Permission Manager has been acquired

Atlassian has acquired the Ultimate Permissions Manager app. For more details, please see the Atlassian blog post and META-INF blog post

Effective May 3, 2019, this app has been removed from the Marketplace and is no longer available for purchase or maintenance renewal. In accordance with Atlassian's End of Life policy, the Ultimate Permissions Manager app will have support for two years, with an end of life date of May 3, 2021. While the app is supported, please raise issues with Atlassian directly via support.atlassian.com.

Nem szükséges aggódni, nem olyan rémisztő ez a hír, mint elsőre gondolhatnánk!

A JIRA7 kiadása talán az eddigi legnagyobb változás a termék életében. Az Atlassian bejelentette, hogy a JIRA ezentúl 3 különböző termékként folytatódik az egyes célcsoportok igényeire fókuszálva

  • JIRA Core, az üzleti folyamatokat kezelő csapatok számára
  • JIRA Software, az agilis csaptoknak
  • JIRA Service Desk, az ügyféltámogatást végzők számára

GYIK

Összegyűjtöttünk néhány hasznos információt ezzel az igen jelentős változással kapcsolatban, valamint összeszedtük, hogy milyen előnyöket jelent ez az új irány az ügyfelek számára.

Jelenlegi JIRA termékek alapértelmezés szerint JIRA Software-re újíthatóak meg

Amennyiben JIRA Core vagy JIRA Service Desk-re szeretne frissíteni, akkor az Atlassian közreműködése szükséges. Lépjen velünk kapcsolatba, és készséggel segítünk a hosszabbítási eljárást gördülékenyen megvalósítani.

Az egyes termékek szerepe a piacon

A JIRA Core az a termék, mely leginkább hasonlít az eddigi "tiszta" JIRA alkalmazáshoz, ellenben egyre inkább az üzleti folyamatokat kezelő csapatok pl. HR, pénzügy, beszerzés igényeire fókuszál majd.

A JIRA Software a korábbi JIRA és JIRA Agile kombinációja egyetlen termékben, és megoldást jelent egy agilis csapat összes jellemző igényére.

A JIRA Service Desk a korábbi JIRA és JIRA Service Desk kiegészítő kombinációja, egy új köntösbe öltöztetve, mely kielégíti egy ügyféltámogatással foglalkozó csapat legfontosabb igényeit. 

Részletesebb információ az alábbi link segítségével érhető el az Atlassian dokumentációs rendszerében: https://confluence.atlassian.com/migration/jira-7/server_jira+agile+jsd_product-changes

A JIRA6 termékkulcs frissítése JIRA7-re

A folyamat nem bonyolult. Az Atlassian közzétett egy nagyon részletes felhasználói leírást arról, milyen lépései vannak egy termékkulcs cserének. A dokumentáció itt érhető el: https://confluence.atlassian.com/migration/jira-7/server_jira+agile+jsd_license-changes

Specializált termékek az eltérő igényekkel rendelkező csapatok kiszolgálására

Az agilis csapatoknak, üzleti folyamatokkal foglalkozó vagy terméktámogatást nyújtó csapatoknak teljesen eltérő funkció igényeik lehetnek egy JIRA-val kapcsolatban. Az Atlassian éppen ezért hozott létre 3 különböző fejlesztői csapatot, akiknek feladata ezen eltérő elvárásoknak való megfelelés.

Mindhárom verziója a JIRA-nak különböző alapértelmezett munkafolyamatokkal, feladat-, és projekt típusokkal valamint eltérő felhasználói felülettel érkezik.

Még az is előfordulhat, hogy kevesebbe kerül a JIRA hosszabbítása!

Mostantól a 3 különböző termék, 3 különböző felhasználói szinttel vásárolható meg.

Képzeljük el az alábbi szituációt: A csapat 20 fejlesztőből, és 15 további munkatársból áll, akik az üzleti folyamatokat kezelik. Korábban ehhez egy 50 felhasználós JIRA-ra volt szükség, melyhez egy JIRA felhasználó számával azonos létszámban, azaz 50 felhasználóig terjedő korláttal kellett JIRA Agile kiegészítőt vásárolni. Ezentúl elegendő 25 felhasználóra JIRA Core és 25 felhasználóra JIRA Software termékkulcsot vásárolni. Szóval megspóroltuk 25 felhasználónyi JIRA Software termékkulcs árát!

Sőt, még a kiegészítők árai is csökkenhetnek!

A kiegészítők felhasználói korlátjának a 3 JIRA termék közül a legmagasabb felhasználó számmal rendelkezővel kell megegyeznie, azaz ha egy 25 felhasználós JIRA Software és egy 50 felhasználós JIRA Core áll rendelkezésre, akkor nem szükséges 100 felhasználós kiegészítőt vásárolni, hanem csak elég 50-es!

Lépjen velünk kapcsolatba - állunk rendelkezésre

Amennyiben további kérdés merülne fel, melyre nem találta meg a választ, lépjen velünk kapcsolatba, és igyekszünk mihamarabb segítségére lenni. /display/en/2016/01/11/Atlassian+will+never+release+JIRA+any+more

2007 óta vagyunk "Atlassian Experts" partnerek, és hiszünk az Atlassian és az Atlassian ökoszisztéma különlegességében. Ez elhivatottá tesz bennünket a mindennapok során. A hosszú évek alatt összegyűlt tapasztalatunkkal segítjük a vállalatokat hatékonyabban dolgozni, fejleszteni a folyamataikat, és az elérhető legjobb eszközök segítségével kiaknázni a bennük rejlő lehetőségeket. Szolgáltatásaink mellett számos népszerű és díjnyertes Atlassian termék fejlesztői vagyunk, melyek igyekszenek speciális igényekre is megoldást kínálni, és segíteni, hogy használatukkal a munka hatékonyabb és örömtelibb legyen.

2015 során elhatároztuk, hogy (újra) elindítjuk Atlassian Expert Blogunkat azzal a céllal, hogy tudásunk és tapasztalatunk terjesztésével segíthessük az Atlassian közösséget. Maradjon velünk, és tanuljunk együtt arról, hogyan hozzunk létre különösen hatékony megoldásokat Atlassian környezetben.

Terveink szerint az alábbi témaköröket öleljük fel

  • praktikus és gyakorlati tippek, trükkök
  • esettanulmányok, és ügyfél sztorik
  • hírek az Atlassianról és az Atlassian termékekről
  • Atlassian Marketplace termékek tesztje, és áttekintése
  • META-INF hírek
  • és egyéb érdekességek az Atlassian világához kapcsolódóan

Hiányzik innen valami? Tud egy nagyon érdekes témát? Esetleg egy remek történetet? Írja meg nekünk, és legyen ebből a következő blog bejegyzés! /pages/viewpage.action?pageId=38895879