Toto je starší verze dokumentu!


Uživatelé

2017/03/24 14:19 · kourim

Jak vést pohovor

  • Co ho na programování baví a co ne - co by měl/chtěl dělat tak, aby ho to bavilo
  • Prověřit na čem dělal - jak se to shoduje s tím, co potřebujeme my?
    • co používá (osx, linux, wokna)?
    • jaké programovací jazyky? nějaké zajímavé technologie?
    • jaké databáze?
    • admin skill na linux?
    • konkrétní projekty, na kterých pracoval? co z toho je k vypichnutí jako fakt zajimavá feature?
    • jak vedli tým(scrum, canban, waterfall, jiné)?
    • jak testovat aplikace?
  • Probrat/ukázat nějaký kus kódu
2017/03/10 14:34 · kourim

Procesy

  • kazdy web ma nadefinovany svuj jeden projekt v jire, k nemu je prirazen projektak/projektaci
  • existuji dalsi projekty, ktere nejsou vazany primo na web, ale vazou s k funcnosti/pouzitelnosti, napr pro devare maintanance and operations
  • existuje vzdy jeden sprint, vyjimkou je, pokud dojde k zalozeni specialniho projektu, pro ktery byl dedikovan cely tym, tento tym ma pak svuj vlastni sprint, board a …
  • pokud projekt skonci, je potreba ho uzvarit, aby se jiz nedal pouzivat a „neprekazel“
  • tasky
    • produktak prirazuje tasky do svyho projektu
    • nastavuje jim typ → bug, frontend feature, backend feature, config
    • nastavuje jim prioritu → nizka, stredni, vysoka, kriticka(nejvyssi)
    • jasne definuje zadani, doplni o odkazy pripadne screenshoty, grafiku apod., tasky bez popisku nebudou akceptovany, popisek != title
  • tasky se podle typu a priority rozdeluji do backlogu(medium/low priority bug, f/b feature, medium/low priority config) a do helpdesk kanbanu(high/crit bugy, high/crit config)
  • flow tasku
    1. tasky, ktere je potreba zpracovat nasledujici sprint, je potreba zadat do jiry nejpozdeji utery vecer
    2. pred poradou vyvoje(streda dopoledne, utery odpoledne) dojde frontend/backend oddelenim na ohodnoceni tasku storypointy
    3. pokud dojde k vytvoreni tasku ve stredu a je potreba ho zpracovat, ?mel by projit schvalenim? a nasledne je ohodnocen, to samy plati i pro tasky pridavane do aktualniho sprintu, task by mel byt vymenen 1:1 s jinym taskem/tasky(podle SP)
    4. na porade vyvoje dojde
      • k alokaci lidi, tz. rozdeleni na vyvoj a helpdesk, vytvareni dedikovanych tymu pro specialni projekty
      • k serazeni backlogu, muze dojit k prirazenim tasku na konkretni lidi(ale nemusi!)
    5. po porade vyvoje se zacne novy sprint, do sprintu se nahazi veci ze serazeneho backlogu, priradi se lidi(ale nemusi)
  1. meetings
    1. grooming party → 2h backend/frontend zvlast
    2. porada vyvoje → 1,5h produktaci + vedeni
    3. sprint meeting → 1h backend/frontend dohromady
2017/03/10 14:30 · kourim

Zamezení pushe do master větve

#!/bin/sh
log="$PWD/hooks/push.log"
protected_branch="master"
policy="nemate opravneni"
allow="uzivatel"
 
do_exit(){
  echo "! ! ! ! ! ! !"
  echo $policy
  echo "! ! ! ! ! ! !"
  echo $policy >> $log
  exit 1
}
 
while read oldrev newrev refname
do
    uname=$(git log $refname)
    branch=$(git rev-parse --symbolic --abbrev-ref $refname)
    if [ "$protected_branch" = "$branch" ]; then
        un=$(git log -1 --pretty=format:%an $newrev)
        echo "Zapis do $protected_branch uzivatelem $un" >> $log
        if [ "$allow" != "$un" ]; then
             #echo $policy >> $log
             policy="\nUživatel $un. Nemáte oprávnění zapisovat do větve: $protected_branch \n"
             do_exit
        fi
    fi
done
 
unset do_exit
 
exit 0

2017/01/19 23:41 · kourim

Starší zápisky >>

  • start.1441105593.txt.gz
  • Poslední úprava: 2015/09/01 13:06
  • autor: kourim