Projektowanie oprogramowania systemów NARZĘDZIA PRACY GRUPOWEJ, KONTROLI WERSJI, DOKUMENTOWANIA I ŚLEDZENIA BŁĘDÓW

Podobne dokumenty
Programowanie I

Co zostanie wypisane na ekranie? (1)

GIT. System Kontroli wersji GIT. Rafał Kalinowski

Git rozproszony system kontroli wersji

Adam Wójs <adam[shift+2]wojs.pl> git --wprowadzenie

Programowanie zespołowe

System kontroli wersji Git

Systemy zarządzania wersjami

Środowisko programisty. Środowisko programisty 1/35

System kontroli wersji git

KOŁO NAUKOWE INFORMATYKÓW SYSTEMY KONTROLI WERSJI CZ.1 16 XII 2009 OPRACOWAŁ: PRZEMYSŁAW PARDEL

Assembla.com zajęcia 1

Git - podstawy. Błażej Kowalczyk. Koło Naukowe Robotyków KoNaR. 7 listopada 2014

CVS system kontroli wersji

Open Source w służbie developerom

Ćwiczenia 9: Zarządzanie konfiguracją Zadania:

System kontroli wersji - wprowadzenie. Rzeszów,2 XII 2010

git krótki przewodnik

Przygotowanie platformy projektowo-programowej

Wprowadzenie do systemu wersjonowania svn

System kontroli wersji, system zarządzania kodem źródłowym

SVN sojusz, partnerstwo, współpraca

Rozproszony system kontroli wersji GIT. Piotr Macuk

Platformy programistyczne:.net i Java WYKŁ AD 1: WPROWADZENIE

Git i platforma GitHub

Tworzenie dokumentacji

Systemy Kontroli Wersji

SUBVERSION TOMASZ ŁUKASZUK

Tworzenie oprogramowania

Jak usprawnić tworzenie i zarządzanie stroną na drupalu. Maciej Łukiański

Platforma GitHub. 1 Cel laboratoriów. 2 GitHub. 2.1 Git. źródeł.

Git, Bitbucket, IntelliJ IDEA

Partnerzy: Laboratorium 15

Narzędzia programistyczne - GIT

Drupal i GIT. Schemat pracy.

Gra-zabawka dla niemowląt przygotowana z użyciem w Unity 3D

Michał (plucho) Subversion Wykorzystanie i administracja repozytorium

Git, Bitbucket. Narzędzia i środowiska programistyczne. Laboratorium 2. Prowadzący: Kierunek: Semestr: Rok: Tomasz Gądek Informatyka Zimowy 2

REFERAT PRACY DYPLOMOWEJ

Javadoc. Piotr Dąbrowiecki Sławomir Pawlewicz Alan Pilawa Joanna Sobczyk Alina Strachocka

Krótka Historia. Co to jest NetBeans? Historia. NetBeans Platform NetBeans IDE NetBeans Mobility Pack Zintegrowane moduły. Paczki do NetBeans.

Platformy programistyczne:.net i Java WYKŁ AD 1: WPROWADZENIE

Zapytanie ofertowe nr 1/IAP/2013 ( dotyczy modułu nr 1/IAP )

ZARZĄDZANIE DOKUMENTACJĄ. Tomasz Jarmuszczak PCC Polska

Zarządzanie projektami informatycznymi

Subversion - jak dziaªa

System zarządzania wersjami I Subversion

Program szkolenia: Continuous Integration i Git

Środowisko NetBeans. Paweł Boguszewski

Programowanie Zespołowe

Technika mikroprocesorowa. Struktura programu użytkownika w systemie mikroprocesorowym

Programowanie zespołowe

Tak. Konrad Ktoso Malawski blog.project13.pl - SFI

egroupware czy phpgroupware jest też mniej stabilny.

MBUM #2. Zarządzanie kopiami konfiguracji RouterOS. Jacek Rokicki

Laboratorium 1 Temat: Przygotowanie środowiska programistycznego. Poznanie edytora. Kompilacja i uruchomienie prostych programów przykładowych.

Język JAVA podstawy. wykład 1, część 2. Jacek Rumiński. Politechnika Gdańska, Inżynieria Biomedyczna

Inżynieria oprogramowania- Grupa dra inż. Leszka Grocholskiego II UWr 2009/2010. Aleksandra Kloc, Adam Grycner, Mateusz Łyczek. Wasza-fota.

FORMA SZKOLENIA MATERIAŁY SZKOLENIOWE CENA CZAS TRWANIA

DSL w środowisku Eclipse. Grzegorz Białek Architekt techniczny, Sygnity S.A.

Użytkowanie PortableGit w systemie Windows. 1. Najważniejsze informacje

Autor: Bączkowski Karol Promotor: dr inż. Paweł FIGAT

GIT. Rozproszony system kontroli wersji

Przygotowanie do nowoczesnego programowania po stronie przeglądarki. (HTML5, CSS3, JS, wzorce, architektura, narzędzia)

Dokument Detaliczny Projektu Temat: Księgarnia On-line Bukstor

1. System kontroli wersji Instalacja programu kontroli wersji CVS

ponad pracowników ponad pracowników ponad pracowników ponad pracowników

System Zarządzania Dystrybucją

Programowanie Komponentowe WebAPI

Projekt i implementacja narzędzia do analizy modeli spójności F R Y D E R Y K R A C Z Y K K O N R A D S Z A Ł K O W S K I

Platformy Technologiczne

PERFORCE SYSTEM KONTROLI WERSJI W ZASTOSOWANIACH

PLAN WYNIKOWY PROGRAMOWANIE APLIKACJI INTERNETOWYCH. KL IV TI 6 godziny tygodniowo (6x15 tygodni =90 godzin ),

PLAN WYNIKOWY PROGRAMOWANIE APLIKACJI INTERNETOWYCH. KL III TI 4 godziny tygodniowo (4x30 tygodni =120 godzin ),

Politechnika Poznańska, Instytut Informatyki, Studia niestacjonarne. Inżynieria oprogramowania

PRACA GRUPOWA Z WYKORZYSTANIEM REPOZYTORIUM PROJEKTU

Programowanie w C. dr inż. Stanisław Wszelak

Projektowanie baz danych za pomocą narzędzi CASE

Biorąc udział w projekcie, możesz wybrać jedną z 8 bezpłatnych ścieżek egzaminacyjnych:

Bezpieczeństwo systemów komputerowych

Rok akademicki: 2012/2013 Kod: IET SW-s Punkty ECTS: 3. Kierunek: Elektronika i Telekomunikacja Specjalność: Systemy wbudowane

XQTav - reprezentacja diagramów przepływu prac w formacie SCUFL przy pomocy XQuery

Zapytanie ofertowe nr 2/IAP/2013 ( dotyczy modułu nr 2/IAP )

Microsoft Visual SourceSafe uproszczona instrukcja użytkowania

Organizacja zajęć BAZY DANYCH II WYKŁAD 1. Plan wykładu. SZBD Oracle

Technologie Komponentowe. Piotr Łukasik p /

GM System. Solid Edge Technical Publications Oferta produktu

Zacznij Tu! Poznaj Microsoft Visual Basic. Michael Halvorson. Przekład: Joanna Zatorska

Narzędzia podnoszące jakość procesu wytwarzania i wdrażania

Wybrane narzędzie do zarządzania błędami - Bugzilla. Krzysztof Palinka Konrad Błaszkiewicz grupa nr 27

Systemy kontroli wersji

Instrukcja instalacji oprogramowania dla środowiska Windows

Przegląd i ewaluacja narzędzi do szybkiego tworzenia interfejsu użytkownika (RAD).

Platformy programistyczne:.net i Java WYKŁ AD 1: WPROWADZENIE

Instrukcja użytkownika Platforma transakcyjna mforex Trader dla systemu Linux

To sposób w jaki użytkownik wchodzi w interakcje z systemem. Środowisko graficzne używa kombinacji graficznych elementów(przyciski, okna, menu) i

System kontroli wersji SVN

PLATFORMA ACTIVE FORMS. Kreator Formularzy Internetowych ze wsparciem dla RWD

Uniwersytet Warszawski Wydział Matematyki, Informatyki i Mechaniki. Paweł Parys. Nr albumu: Aukcjomat

Transkrypt:

Projektowanie oprogramowania systemów NARZĘDZIA PRACY GRUPOWEJ, KONTROLI WERSJI, DOKUMENTOWANIA I ŚLEDZENIA BŁĘDÓW

plan wykładu Narzędzia pracy grupowej Edycja grupowa w czasie rzeczywistym Narzędzia Systemy kontroli wersji Podejście rozproszone kontra klient-serwer Wspólny słownik i koncepcje Narzędzia Narzędzia generowania dokumentacji Metajęzyki dokumentowania API Narzędzia Systemy śledzenia błędów Cykl życia bug-a Narzędzia

edycja grupowa w czasie rzeczywistym Jak to działa? Zespół (para?) programistów pracuje równocześnie nad tym samym fragmentem kodu Zmiany wprowadzone przez któregokolwiek z członków zespołu są natychmiast widzialne w każdej kopii w ten sam sposób co edycja w Google Docs Do czego to służy? Programowanie w (rozproszonych) parach na sposób XP - natychmiastowa komunikacja między członkami zespołu prowadzi do lepszego zrozumienia logiki kodu przez programistów (w tym piszącego), co skutkuje lepszą jakością kodu Przegląd kodu - jeden członek zespołu wykonuje przegląd kodu w tej samej chwili gdy inni piszą

narzędzia programowania ekstremalnego specjalne krzesło albo grupowy, rozproszony edytor

typowe cechy Cechy komunikatora internetowego: Roster (lista użytkowników) Chat (grupowy i jeden-dojednego) Współdzielona tablica Edytor kodu Podkreślanie/kolorowanie składni Kolorowanie autorów Wizualizacja obszaru edytowanego przez innych

narzędzia Historycznie pierwsze sensowne podejście SubEthaEdit na Macu (komercyjny) Gobby edytor grupowy OpenSource (Unix, Mac, Windows) Działa w trybach p2p i klient-serwer Protokół Obby używany również przez inne narzędzia, m.in.: GNU Emacs z wtyczką Rudel, kompatybilny z Gobby Wieloplatformowy

narzędzia Microsoft Visual Studio wtyczka VS Anywhere Komercyjna (darmowa dla studentów) Tylko tryb klient-serwer

narzędzia Eclipse wtyczka Saros Darmowa Opiera się na standardowym protokole komunikatorowym - XMPP

systemy kontroli wersji kodu (VCS: version control systems) Zarządzanie zmianami kodu na przestrzeni czasu Każda zmiana kodu jest przechowywana ( popełniana ) do repozytorium i jest powiązana z autorem, numerem wersji (rewizji) i datą Członkowie zespołu pobierają ( check out ) pliki projektu z repozytorium i pracują na kopii lokalnej ( kopii roboczej ) Po napisaniu porcji kodu zmiany są wysyłane do repozytorium Pozostali członkowie zespołu uaktualniają swoje kopie robocze, pobierając popełnione zmiany

do czego to służy? Pozwala cofnąć się do dowolnego punktu w historii projektu np. kiedy zmiany kodu powodują nowe błędy, można to łatwo wyśledzić Dodatkowa kopia bezpieczeństwa projektu Z każdą popełnioną zmianą można powiązać znaczący komentarz Umożliwia tworzenie równoległych gałęzi (branches) kodu, w których rozwijane są nowe cechy Umożliwia odnaleźć winnych błędów ;>

co należy przechowywać w repozytorium VCS Kod źródłowy (poza plikami generowanymi automatycznie) Pliki projektu (poza konfiguracją specyficzną dla maszyny/użytkownika) Zasoby projektu (grafiki, tablice napisów, tłumaczenia ) Skrypty służące do pielęgnacji i budowania projektu (np. skrypty tworzące bazę danych) Wszystko, co niezbędne do zbudowania projektu od zera, a nie jest automatycznie generowane lub dostępne z publicznej lokalizacji

czego nie należy przechowywać w repozytorium Plików źródłowych generowanych automatycznie podczas budowania projektu Plików intermediate i wyjściowych (np..obj,.o, binarnych, symboli debugowania, cache IDE ) Niczego, co jest tworzone automatycznie podczas budowania

architektury VCS Klient-serwer Tradycyjne podejście Repozytorium ulokowane na pojedynczym serwerze (master) VCS Każdy z członków zespołu używa klienta VCS żeby połączyć się z serwerem i pobrać/popełnić zmiany Implementacje: Subversion Visual SourceSave CVS Dużo dużo innych Rozproszona Nowoczesne podejście Jest wiele repozytoriów, każde zawiera pełną lub częściową kopię Repozytoria mogą być synchronizowane między sobą Kopie robocze członków zespołu są również rozproszonymi repozytoriami Implementacje: Git

graf rewizji Rewizje kodu w repozytorium tworzą graf Główna gałąź rozwijana przez cały czas życia projektu to trunk Możliwe dodatkowe gałęzie (branch), np. dla rozwijania eksperymentalnych funkcji Kiedy gałęzie rozwojowe osiągają dojrzałość, mogą być z powrotem włączone (merge) do gałęzi głównej (trunk) Kamienie milowe projektu mogą być oznaczone etykietami (tag), co umożliwia łatwe przełączanie się do wybranego kamienia milowego/wersji oprogramowania Kopia robocza użytkownika może być również postrzegana jako lokalna gałąź, która jest łączona z trunk w momencie kiedy użytkownik popełnia kod (tak to działa w Git)

podstawowe operacje w VCS checkout tworzy lokalną kopię roboczą repozytorium (svn checkout git checkout) commit wysyła zmiany z kopii roboczej do repo (svn commit git commit) merge łączy (synchronizuje) zmiany z dwóch gałęzi, być może powodując przy tym konflikt (svn merge git merge) update uaktualnia lokalną kopię roboczą o zmiany popełnione do repozytorium (svn update git pull) branch/tag tworzy gałąź kodu lub nadaje etykietę bazując na ostatniej rewizji pobranej z repozytorium (svn branch / tag git branch / tag) status status kopii roboczej (svn stat git stat) resolve oznacza konflikty jako rozwiązane (svn resolve git resolve) revert wycofuje zmiany wprowadzne w kopii roboczej (svn revert git revert)

prosty scenariusz użycia svn checkout <remote repository url> [local path] tworzy kopię roboczą z repo edycja kodu, dodawanie nowych plików svn commit m [project] added file test.c popełnia lokalne zmiany do zdalnego repo git clone <remote repository url> [local path] tworzy lokalną kopię repo, ustawia zdalne repo jako kopię źródłową edycja kodu, dodawanie nowych plików git commit m [project] added file test.c popełnia zmiany z kopii roboczej do lokalnego repo git push origin synchronizuje zmiany z lokalnego repo do zdalnego źródła

prosty scenariusz użycia svn stat svn update svn add test2.c sprawdź status kopii roboczej włącz zdalne zmiany do kopii roboczej dodaj nowy plik do kopii roboczej svn commit m [project] added file test2.c popełnij lokalne zmiany do zdalnego repo git stat git pull sprawdź status kopii roboczej włącz zdalne zmiany do do lokalnego repo i kopii roboczej git add test2.c dodaj nowy plik do kopii roboczej git commit m [project] added file test2.c git push origin

konflikty wersji Konflikt pojawia się kiedy więcej niż 1 użytkownik równocześnie edytuje to samo Konflikty świadczą o wadliwej komunikacji w zespole projektowym Rodzaje konfliktów Konflikt drzewa zmiana w strukturze plików/katalogów, zmiana nazwy Konflikt edycji wielokrotna edycja tego samego fragmentu plików Konflikt musi być rozwiązany przed możliwością popełnienia zmian do repo

narzędzia Narzędzia linii poleceń svn (Subversion); napisz svn --help git (Git); napisz git --help Narzędzia GUI TortoiseSVN (Windows) TortoiseGIT (Windows) GitHub (Windows/Mac) Git Shell Extensions (Windows)

narzędzia Integracja z IDE (Integrated Development Environment) AnkhSVN (Subversion for Visual Studio) Subclipse (Subversion for Eclipse) Git is integrated by default both in Visual Studio and Eclipse Dodatkowe narzędzia używane przez VCS diff narzędzie UNIX-owe do generowania plików różnic pomiędzy 2 plikami tekstowymi w formacie tzw. unified diff ; diff jest używany przez prawie wszystkie VCS do wymiany informacji o zmianach pomiędzy rewizjami patch UNIX-owe narzędzie do scalania plików diff z plikami źródłowymi

systemy VSC linki https://en.wikipedia.org/wiki/revision_control https://subversion.apache.org/ http://svnbook.red-bean.com/ http://git-scm.com/ http://git-scm.com/book/en/v2

narzędzia automatycznej generacji dokumentacji Pisanie kodu jest zbyt zabawne żeby dodatkowo się rozpraszać pisaniem dokumentacji ;) Narzędzia dokumentowania kodu służą do generowania dokumentacji automatycznie, bazując na kodzie wzbogaconym o dodatkowe tagi dokumentujące Tagi i tak trzeba niestety napisać (w formie komentarzy do kodu), ale przynajmniej nie trzeba przełączać się między edytorem dokumentacji a kodem, wszystko pozostaje w pamięci krótkotrwałej i nie powoduje to dekoncentracji W istocie pisanie dokumentacji API jest bardzo podobne do programowania parami i prowadzi do lepszej jakości kodu poprzez wczesne wyłapywanie usterek

metajęzyki dokumentacji kodu Niektóre języki mają wbudowany metajęzyk dokumentacji, opisany standardem i rozumiany przez kompilator i IDE Java JavaDoc C# - XML Docs Nie ma oficjalnego standardu dla C i C++ Ale jest de facto standard Doxygen Całe szczęście Doxygen rozumie również JavaDoc i XML Docs, więc jest to uniwersalne narzędzie do wszystkiego

cechy doxygen-a Generacja dokumentacji w formatach HTML, PDF, LaTeX, Windows Help, UNIX man i wiele, wiele innych Wsparcie dla wzorów matematycznych (LaTeX), bogatego formatowania i hyperlinkowania kodu Jeden język dokumentowania dla wszystkich sensownych języków programowania

doxygen w akcji

dodatkowe narzędzia GraphViz Graph Visualization Toolbox narzędzie wizualizacji grafów integrujące się z doxygen, pozwala m.in. automatycznie generować niektóre diagramy UML (www.graphviz.org) Manual doxygena: http://www.stack.nl/~dimitri/doxygen/manual/index.html

systemy śledzenia błędzów Każde oprogramoania ma bugi Programiści starają się zapomnieć o wykrytych bugach jak tylko powrócą do pisania kodu (albo nawet szybciej) ;> Systemy śledzenia błędów (issue tracking systems) służą do zarządzania informacjami o błędach i nie pozwalają leniwym programistom o nich zapomnieć

cykl życia buga

cechy systemów śledzenia błędów Interfejs webowy dla zgłaszania bugów i zarządzania informacjami o nich Integracja z repozytoriami VCS Hyperlinkowanie raportów o błędach w komentarzach VCS (#3345) Hyperlinkowanie rewizji kodu (r109) w raportach o błędach Przeglądanie repozytorium VCS z poziomu systemu śledzenia błędów Wysyłanie powiadomień email o zmianach statusu buga Integracja z IDE interfejsy zorientowane zadaniowo

narzędzia Bugzilla system śledzenia błędów oryginalnie stworzony dla przeglądarki Mozilla Trac system śledzenia błędów, zarządzania projektem i Wiki napisane w języku python (Open Source) JIRA system zarządzania wdrożeniami dużej skali i śledzenie błędów (komercyjny) Google Code Wiki projektu, repozytorium kodu i system śledzenia błędów dla projektów Open Source Mantis, Launchpad, GNATS i wiele wiele innych

Następny slajd jest prawdopodobnie najważniejszy w tej prezentacji

wymagania względem Waszego projektu Użycie systemu VCS do zarządzania repozytorium kodu zespołu projektowego Albo serwer dostarczony przez Katedrę, Albo Wasza własna instalacja Git lub SVN, Albo darmowy hosting projektu na GitHub, Google Code lub inny Wyznaczyć jednego z członków zespołu jako maintainer repozytorium odpowiedzialny za jego właściwą strukturę i zachowanie czystości Konsekwentne używanie sensownych komentarzy podczas popełniania zmian kodu Użycie tagów doxygena do dokumentowania Waszego kodu, plik konfiguracji doxygena (doxyfile) przechowywany w repozytorium VCS razem z projektem Użycie systemu śledzenia błędów do zarządzania raportami o bugach Albo serwer dostarczany przez Katedrę, Albo Wasza własna instalacja Trac-a lub Bugzilli (zintegrowana z repo VCS), Albo darmowy hosting projektu, jak wyżej. Integracja w/w narzędzi z wybranym przez Was lub Katedrę IDE