Konfiguracja dużego systemu oprogramowania w Delphi

Zajmę się organizacją folderów. To pochodzi z pakietu oprogramowania, który ma 50 + exe i dll i mnóstwo bibliotek stron trzecich, więc myślę, że wiem, skąd pochodzisz...

Używamy Perforce jako systemu kontroli źródła, więc główny folder mojej domyślnej przestrzeni roboczej nazywa się Perforce, ale mam również kilka innych obszarów roboczych skonfigurowanych i są one w Perforce2, Perforce3, itp.

Ogólna konfiguracja folderu (zaczynając od folderu głównego obszaru roboczego)

General
  Components
    Delphi
      Indy
        Indy9
        Indy10
      MadCollection
        v2.5.8.0
        v2.6.0.0
  Plugins
Releases
  Released
  ... a folder for each release we publish ... (and equal to a branch in Perforce)
Work
  Acceptance
  Sub1
  Sub2

Mój Ścieżka biblioteki środowiskowej w IDE jest pusta(nie ma tam nawet ścieżek standardowych BDE). Zapewnia to, że ścieżki projektu deklarują wszystkie potrzebne ścieżki i że projekty nie są zależne od konfiguracji IDE konkretnej maszyny.

Mamy ustawione w IDE środowisko var (ie MRJ), które wskazuje na "General\Components\Delphi", więc w opcjach projektu deklarujemy ścieżki do naszych komponentów jako $(MRJ)\MadCollection\2.6.0.0.

General posiada wtyczki IDE i komponenty używane przez nasze projekty. We keep all wersje, których używamy w kontroli źródeł. W ten sposób, kiedy muszę wrócić do starego wydania, aby wyśledzić problem, mogę po prostu wyciągnąć go i zbudować go, ponieważ jego ścieżki biblioteczne nadal będą wskazywać na wersję komponentów, których to konkretne wydanie potrzebuje.

Organizacja folderów w danej gałęzi pracy (akceptacja lub jedna z jej podgrup) przebiega według tego wzoru:

General          
  Includes
  MainComponent1
    Project1
    Project2
    Shared
  MainComponent2  
    Project3
    Project4
    Shared
  Shared
Windows          
  SoftwareSuite  
    Scripts
      Tools
  MainComponent1
    Project1
      Dcus
    Project2
      Dcus
  MainComponent2  
  Tools
    Tool1
      Dcus
    Tool2
      Dcus

Folder ogólny zawiera wszystkie niezależne od platformy źródła / pliki, folder Windows zawiera wszystkie Pliki specyficzne dla systemu Windows. Każdy komponent może zawierać wiele projektów i będzie miał folder udostępniony dla źródeł udostępnionych między tymi projektami. Folder udostępniony bezpośrednio w sekcji Ogólne zawiera źródła udostępniane przez wszystkie projekty. Folder Windows jest skonfigurowany w podobny sposób.

Zauważ, że każdy projekt ma swój własny folder DCU . Jest to skonfigurowane w opcjach projektu. Ponieważ ścieżka może być wprowadzona jako .dcus, my (przynajmniej ja) ustawiamy ją jako domyślną dla każdego nowego projektu. Każdy projekt wysyłający swoje DCU do unikalnego folderu zapewnia dwie rzeczy:

• łatwo jest utrzymać dcu poza kontrolą wersji, po prostu ustawiając filtr w oprogramowaniu do kontroli wersji.
• co ważniejsze zapewnia, że kompilacja/budowa projektu nigdy nie ingeruje w kompilację/budowę innego projektu. Mogę bezpiecznie zmienić ustawienia i budować wiedząc, że nie będzie mi przeszkadzało leżenie dcu z poprzedniej kompilacji z innego projekt.

Polecam następujące praktyki:

1. Zachowaj prostą ścieżkę biblioteki i upewnij się, że wszystko w ścieżce biblioteki jest albo folderem dostarczanym z delphi, albo folderem binarnym (biblioteki) DCU w Twoim d:\Components \ folder.

2. Użyj nowoczesnego typu kontroli wersji. Polecam Mercurial nad innymi. Źródło Bezpieczne to gówno, przestań go używać.

3. Utwórz kopię zapasową swojego środowiska (klucze rejestru eksportu itp.) i przywróć je do innych komputerów deweloperskich w ustandaryzowany sposób. Możesz zatrzymać kilka .reg i .pliki cmd (wsadowe) w celu automatyzacji konfiguracji nowego systemu. możesz umieścić te skrypty w repozytorium komponentów w systemie kontroli wersji.

Poza zakresem, który był w dużej mierze omawiany wcześniej, polecam :

• testy jednostkowe - z Dunitem na przykład
• ciągła integracja. Żeby mieć pewność, że wszystkie te projekty mogą się skompilować na innej maszynie i że testy są w porządku.

Jest to więc mocno związane z organizacją projektu i strategią VCS.

Dla podobnej konfiguracji, firma, dla której pracowałem, uznała tę konfigurację za przydatną:

• wszystkie biblioteki stron trzecich (komponenty itp.) go to a fixed location (C:\Delphi\name-version)
• projekty Delphi mogą być sprawdzane z poziomu kontroli wersji w dowolnym miejscu (napęd C: lub D: i nazwa folderu nie ma znaczenia), ponieważ wszystkie projekty i skrypty używają ścieżek względnych
• wszystkie projekty są podfolderami jednego głównego folderu projektu, więc sprawdzenie tego spowoduje, że projekty Delphi i innych odpowiednich zasobów do stacji roboczej, a aktualizacja kontroli wersji jest łatwa do zrobienia
• używamy skryptu build (napisanego w Apache Ant), który znajduje się w głównym folderze i iteruje we wszystkich folderach, aby zbudować Aplikacje Delphi i uruchomić testy jednostkowe i integracyjne na deweloperskim serwerze bazy danych, aby sprawdzić, czy wszystkie zmiany działają przed sprawdzeniem kontroli źródła
• skrypt build może być również uruchamiany automatycznie na build server (Hudson CI) na każdym commit to see if something broke

I notatka o bibliotekach komponentów: unikaj instalacji pakietu tam, gdzie to możliwe, preferuj tworzenie komponentów w czasie wykonywania. Jeśli szybko musisz zastosować poprawkę do pięcioletniej wersji projektu, odinstalowanie / zainstalowanie kilkunastu pakietów może stać się frustrujące. Przynajmniej w przypadku komponentów niewizualnych tworzenie w czasie wykonywania to ogromna oszczędność czasu.

Sprawdzanie kodu stron trzecich w kontroli źródeł może być bardzo pomocne, na przykład aby udostępnić poprawki, które nie są jeszcze dostępne jako nowe oficjalne wydania. Najlepsze praktyki omówiono w rozdziale dokumentacja programu Subversionoddziały sprzedawcy. Dodatkowo, dzięki Subversion możesz użyć svn:externals , aby umieścić określoną wersję (tag) bezpośrednio w strukturze katalogów projektu. Może być używany zarówno z bibliotekami innych firm, jak i z własnym kodem źródłowym, co ułatwia zarządzanie zależnościami i konfigurację stacji roboczej.

P. s. skrypt budowy mrówek definiuje ścieżki wyszukiwania dla wszystkiego, więc jest to 'odniesienie' dla wszystkich programistów, jak skonfigurować IDE, gdzie umieścić biblioteki stron trzecich i które flagi kompilatora użyć

P. P. S. Twój projekt brzmi nieźle - jestem otwarty na pracę na umowę zlecenie:)

Mój zespół korzysta z wirtualizacji i kiedy widzimy wstecz, było to naprawdę dobre posunięcie. Używamy laptopów MacBook Pro i VMware Fusion, ale jestem pewien, że inne pakiety działają dobrze, jak VirtualBox lub VirtualPC.

Zawsze dobrze jest wiedzieć, że gdy nowy programista zaczyna lub stara instalacja ma problemy, wystarczy skopiować nowy obraz maszyny Wirtualnej z obrazu głównego, a konfiguracja jest dokładnie jako oryginał. Obraz główny jest przechowywany na szybkim dysku USB2. Teraz, gdy piorun i Zbliża się USB3 byłoby jeszcze szybciej skopiować obraz. I nie ma realnej troski o wydajność na nowoczesnym komputerze, o ile jest pamięć. 8 GB powinno wystarczyć, aby uruchomić 2 obrazy w parallell. Kolejną zaletą wirtualizacji jest to, że tak łatwo jest wypróbować scenariusz What if . Eksperymentuj z różnymi konfiguracjami i wersjami bez ryzyka zakłócenia rzeczywistego środowiska pracy.

Btw też uważam, że SourceSafe to gówno... :-)

Somé porady:

• Utwórz jeden plik groupproject dla wszystkich aplikacji należących do projektu, każda aplikacja w swoim własnym katalogu pod plikiem groupproj

• Powinieneś być w stanie określić, które typy plików należy włączyć do systemu kontroli wersji. Upewnij się, że w Delphi zapisywane są pliki DFM w formacie tekstowym.

• Mozna powiedziec Delphi aby wypisywal DCU w subdirach o nazwie 'dcu' pod kazdym programem (mniej visaul clutter).

• Rzeczy osób trzecich często nalega na instalację w różnych miejscach, niewiele można z tym zrobić. Tworzenie dokumentu opisującego konfigurację kompletnego środowiska pracy i aktualizowanie go

• Rozwijaj w maszynach wirtualnych. Nowy programista otrzymuje kopię maszyny wirtualnej.

• Utrzymanie dla różnych wersji Delphi? Przemyśl to, spróbuj przejść do jednej wersji. Jeśli absolutnie musisz mieć dwa groupprojects i struktury katalogów dla każdej wersji. [Zakładam, że nie kompilujesz ta sama aplikacja z dwiema wersjami Delphi, czyli developer hell]

• Delphi XE2 będzie wyprowadzać do różnych podkatalogów 32/64, co nie powinno sprawiać żadnych problemów.