GoldenLine
Zaloguj się
Łukasz Ważny

Łukasz Ważny winning doesn't
really matter as
long as you win

Temat: Praca zespołowa

Witam

Ciekawych wątków ciąg dalszy, a zatem jak wygląda Wasza praca przy projektach pracując w zespole, jaki sposób organizacji polecacie.

Chodzi mi przede wszystkim o pracę w połączeniu serwer WWW + baza danych + kilku programistów + system kontroli wersji, jakie macie doświadczenia w tym obszarze.

Zwłaszcza w ujęciach www + bd:
- wspólny serwer www + wspólna baza danych
- rozdzielone serwery www pod każdego programistę + wspólna baza,
- rozdzielone serwery www + baza danych pod każdego programistę
- inne?

... i problemy wynikające z wymienionych zestawień - konflikty konfiguracji dla rozdzielonych serwerów, konflikty danych dla wspólnych?

System kontroli wersji:
- raczej jeden trunk dla projektu
- osobne branch'e pod programistę

Zapraszam do dyskusji :)
Link do wypowiedziLink

konto usunięte

Temat: Praca zespołowa

ja tak sobie CZYSTO TEORETYCZNIE mysle, ze standardy pracy powinny byc mniej wiecej takie:

- baza jedna wspolna opracowana przez projektanta, kazde poprawki / aktualizacje wprowadzane TYLKO przez niego (o nazewnictwie tabel/kolumn nie wspominajac)
- programista nie pracuje na "zywym organizmie", kazdy ma swoja baze lokalna, ewentualnie jakis serwer posredni dostepny dla wszystkich programistow (powiedzmy raz dziennie czyszczony i co rano wypelniany baza testowa)

system kontroli wersji oczywiscie tak (jeden dla projektu) pod warunkiem, ze prace programistyczne nie nachodza na siebie w obrebie podkatalogow; w przeciwnym wypadku moze to rodzic konflikty i/lub frustracje.

tak dla smiechu:
kiedys mialem niewatpliwa przyjemnosc pracowac w takim zespole, gdzie tzw. "praca grupowa" polegala na przesylaniu miedzy soba fragmentow zmienionego kodu majlem. kazdemu bym te forme odradzil ;-)
Link do wypowiedziLink
Andrzej Dybionka

Andrzej Dybionka Full Stack Developer

Temat: Praca zespołowa

Wojciech Zbigniew Piotrowicz:
tak dla smiechu:
kiedys mialem niewatpliwa przyjemnosc pracowac w takim zespole, gdzie tzw. "praca grupowa" polegala na przesylaniu miedzy soba fragmentow zmienionego kodu majlem. kazdemu bym te forme odradzil ;-)
Nie no super :)

Obecnie, że znajomymi korzystamy z SVN-a, każdy ma swoją kopie bazy na lokalnym serwerze. Jeżeli są duże zmiany w bazie (tabele, kolumny) to baza jest budowana od nowa i wypełniana nowymi, przykładowymi danymi poprzez napisany skrypt.
Serwer główny jest updetowany dopiero wtedy jak mamy pewność co do stabilności wykonanych rzeczy.Andrzej Dybionka edytował(a) ten post dnia 03.04.08 o godzinie 10:46
Link do wypowiedziLink

konto usunięte

Temat: Praca zespołowa

Co do plików to korzystam z montowania przez ssh, czas dostępu do plików niezauważalny, budowanie.. hmm musiałoby być bardzo dużo zmian w krótkim czasie żeby były jakieś problemy ( ja nie zauważyłem ).

W pracy mam podział na osobę od widoków, od bazy danych i od kontrolerów, więc
edytowanie pliki rzadko się pokrywają. A że Eclipse ma historię zmian to problemy przy nadpisaniu plików wielkiego nie ma. Przy większej ilości programistów zaprzągł bym svn'a.Michał Wujas edytował(a) ten post dnia 03.04.08 o godzinie 11:48
Link do wypowiedziLink

konto usunięte

Temat: Praca zespołowa

Abstrahując od tego czy to PHP, czy JavaScript czy jeszcze coś innego:

Kontrola wersji przydaje się przy zespole większym niż dwóch programistów.

Osobne, lokalne środowiska dla każdego programisty to dobre rozwiązanie, ale oczywiście jest to też narzut administracyjny (aktualizacje, konfiguracje - robią to programiści czy administratorzy to i tak jest to zwielokrotniony narzut).

Przy większych projektach przydaje się co najmniej jedno środowisko "integracyjne" gdzie zmiany spotykają się i są scalane przed wysłaniem na produkcję. Można też na tym środowisku testować poprawność skryptów aktualizujących bazę / pliki.
Link do wypowiedziLink
Adam Brodziak

Adam Brodziak PHP, football, fun

Temat: Praca zespołowa

System kontroli wersji przydaje się zawsze, nawet jak jest jeden programista. Inna sprawa czy to ma być system zcentralizowany (SVN), czy rozproszony (git, bazaar, mercurial). Wydaje mi się, że przy zespole większym niż 5 osób lepszy będzie rozproszony, szczególnie jeśli koderzy nie mają bezpośredniego kontaktu (nie siedzą w jednym biurze). Przy rozproszonym systemie nie trzeba się gimnastykować i tworzyć branchy dla każdego, bo koder ma własne środowisko kontroli wersji które można łatwo synchronizować z innymi. Do poczytania: http://blog.zabiello.com/articles/2008/03/19/distribut...

Co do bazy, to każdy powinien posiadać swoją kopię developerską w odpowiedniej wersji. Niestety, nie znam systemu kontroli wersji dla baz danych, dlatego trzeba sobie jakoś radzić z wersjonowaniem. Dodatkowo przydają się pliki .sql z zapisanymi komendami do tworzenia środowiska (CREATE, podstawowe INSERT), które także są w systemie kontroli wersji i są aktualizowane w miarę zmian.

Serwer developerski (www+php+baza+svn) dla wszystkich to fajna rzecz, ale wiąże się z tym trochę problemów.
Link do wypowiedziLink
Rafał Korszuń

Rafał Korszuń co-owner @ Kleder

Temat: Praca zespołowa

ja znam jeszcze inny model pracy zespołowej, który się sprawdzał:

1. dla każdego programisty lokalna wersja kodu + jedna wspólna baza developerska

2. serwer testowy (aplikacji) korzystający z baz produkcyjnych

3. wersja produkcyjna + bazy danych produkcyjne (replikacja)

synchronizowanie kodu na poziomie svn

procedura przeniesienia kodu do systemu produkcyjnego wyglądała tak:
commit + automatycznie przeniesienie kodu na serwer testowy (na którym pracowali użytkownicy wewnętrzni firmy)
po zatwierdzeniu przeniesienie na "zewnątrz" (ręczne)

taka procedura pozwalała na utrzymanie kontroli nad zmianami w bazie danych.
Link do wypowiedziLink
Andrzej Dybionka

Andrzej Dybionka Full Stack Developer

Temat: Praca zespołowa

Adam Brodziak:
Niestety, nie znam systemu kontroli wersji dla baz danych, dlatego > trzeba sobie jakoś radzić z wersjonowaniem. Dodatkowo przydają się > pliki .sql z zapisanymi komendami do tworzenia środowiska (CREATE, > podstawowe INSERT), które także są w systemie kontroli wersji i są > aktualizowane w miarę zmian.

Chyba, że korzysta się z jakiegoś framworka który zarządza bazą automatycznie np. Django.
Link do wypowiedziLink
Rafał Korszuń

Rafał Korszuń co-owner @ Kleder

Temat: Praca zespołowa

Andrzej Dybionka:

Chyba, że korzysta się z jakiegoś framworka który zarządza bazą automatycznie np. Django.

Tak ale jednak z "magiczną" optymalizacją zapytań to nie działa najlepiej

szczególnie gdy się używa proxy dla systemu db i pewnej grupy replikowanych serwerów zaczynają się schody

+ do tego wszystkiego systemy współdzielenia pamięci pomiędzy procesami PHP aby zminimalizować ilość zapytań oraz przechowywać wygenerowane strony
Link do wypowiedziLink
Jakub L.

Jakub L. Programista

Temat: Praca zespołowa

Programiści mogą spokojnie pracować zdalnie na jednej maszynie i jednym serwerze www - każdy będzie miał swój kod w osobnym katalogu dostępnym przez ten serwer.
Odpada problem różnych konfiguracji serwera (które też powinny być trzymane w systemie wersjonowania).
Baza - jeżeli pracują zdalnie na tej samej maszynie to podobnie jak www - jeden serwer, kilka instancji bazy. Skrypty SQL w repozytorium.

Taka konfiguracja powoduje, że łatwo jest ja przenieść na inną maszynę, bo po prostu wyciąga się konfigi z repozytorium, a programiści są w stanie zobaczyć, co koledzy robią na tej samej maszynie (przy odpowiednio nadanych prawach).

Kwestia organizacji repozytorium jest odbiciem podziału odpowiedzialności, bo jeżeli każdy programista będzie miał swój branch, to ktoś musi koordynować zmiany głównej linii developementu.
Równie dobrze mogą jechać na jednej linii, annotate/blame ich przyjacielem :)
Link do wypowiedziLink

konto usunięte

Temat: Praca zespołowa

Adam Brodziak:
Dodatkowo przydają się pliki .sql z zapisanymi komendami do tworzenia środowiska (CREATE, podstawowe INSERT), które także są w systemie kontroli wersji i są aktualizowane w miarę zmian.

Tutaj polecam świetny ORM do PHP - phpdoctrine.
Bazę danych możemy stworzyć prosto z modelów - więc odpada bawienie z dumpami bazy danych, synchronizacją plików sql itp.
Dane testowe można sobie wczytywać do nowo utworzonej bazy z plików yaml. W plikach yaml możemy w bardzo wygodny sposób definiować połączenia pomiędzy tabelami, a nawet możemy umieszczać fragmenty kodu php ;)
Migracji jeszcze nie testowałem, ale chyba nie są tak dojrzałe jak Ruby On Rails.
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy


Następna dyskusja:

pytanie - praca na zlecenie...




Wyślij zaproszenie do
Anuluj