Witam wszystkich serdecznie,
zaznaczam, że nie wiedziałem dokąd ten topic dać, uznałem że tutaj będzie mu najbliżej.

Jestem autorem skryptu, który z swojej natury raz na jakiś czas podlega zmianom ( z reguły niewielkim ) - crawluje on bowiem po pewnych serwisach internetowych, które raz na jakiś czas coś zmieniają, co skutecznie blokuje działanie.

Skrypt ten już działa na parunastu serwerach klientów i zaczęło być męczące wrzucanie wszystkich updatów ręcznie. Zastanawiam się nad rozwiązaniem. Myślałem o stworzeniu prywatnego SVN, z serwerów produkcyjnych zrobić checkout i
svn update as needed. Chociaż to tez jest takie, no.. osobiście wolałbym uniknąć konieczności włażenia na kazdy z tych serwerów. Może rsync się nada?

Oprócz proponowanego rozwiązania, fajnie by było wiedzieć jak rzeczony problem się nazywa, gdyż jeszcze jestem dość niedoświadczony, a jestem wręcz pewien że ma to swoją nazwę.

Dzięki wielkie z góry.

Witam,

W niedługim czasie stanę przed podobnym problemem, również mam aplikację, która będzie wymagała aktualizacji. Osobiście też myślałem nad repozytorium, ale nie svn tylko git, z tego powodu, że będę posiadał większą elastyczność (lokalne repozytoria).

Zasada działania była by taka, że każdy klient ma swoje repozytorium lokalne połączone ze zdalnym (git remote). Jako że posiadam serwer dedykowany jestem w stanie każdemu userowi przypisać zadanie cron'a, w którym zostaje odpalony skrypt sh powiedzmy raz na tydzień albo miesiąc.

Kolejno wykonując komendy:



Mniej więcej tak by to wyglądało, jest to tylko wstępna koncepcja, ale generalnie zasada była by właśnie taka. Jestem za tym, aby to git był odpowiedzialny za aktualizacje, dodatkowo fajnie by było to uzupełnić o kolejne branche, np. każdy klient posiada również swój zdalny branch co umożliwi wersjonowanie aplikacji klienta w przypadku, w którym będzie chciał ją dostosować wg. własnym potrzeb.

Oczywiście jest to tylko concept bo sam nie wiem jeszcze czy to się sprawdzi.

Do głowy jeszcze przychodziło mi unixowe patch, ale mając możliwość korzystania z repo nie ma to sensu.

Pzdr.

Osobiście rozwiązywałem to w zupełnie inny sposób. Z uwagi na to, że różni klienci dają różny dostęp, od FTP przez SVN do SSH z dużymi ograniczeniami zatem postanowiłem pójść metodą skryptową. Skrypt przy każdym wykonaniu sprawdza czy istnieje plik gdzieś w jakimś nie publicznym folderze (konfigurowalnym) po prostu z date('Ymd'), jeżeli go nie ma to porównuje swoją wersję z wersją, którą próbuje pobrać z mojego serwera, czytanie z pojedynczego pliku realizuje przez file_get_content(). Jeżeli wersja nie jest zgodna to odpalam aktualizacje, to jest pobieranie pliku z mojego serwera i aktualizacja mojego. Na niektórych serwerach oczywiście pojawił się problem z brakiem praw do pisania w pliku, który jest uruchamiany, zatem rozwiązałem to znaną metodą linku symbolicznego. Ładuje nowy plik i podmieniam symlinka.

Dzięki temu można aktualizować skrypty jedno, dwu plikowe. Zatem jeżeli o takie rozwiązanie chodziło i jest to problem do zrealizowania na różnych maszynach z różnym dostępem to jest to dobra opcja. Oczywiście odradzam maksymalnie ile mogę aktualizowanie tą metodą więcej niż 2 plików i dla serwisów o raczej dużej oglądalności.

Dla serwisów o dużej oglądalności i dużej ilości plików raczej korzystam z svn - dla takich projektów zawsze mam dostęp po ssh, więc mam po prostu skrypt czytający z pliku host:login:haslo, łączący się, wchodzący i wykonujący kolejny skrypcik "up", w którym to po prostu jest wywołanie svn up z odpowiednimi dla danego serwera parametrami jak ścieżki czy konieczność wywalenia cachu, zmiany praw itd itp. Coś na zasadzie klient-serwer, mój serwer podłącza się i nakazuje klientowi zrobić update. To dobre rozwiązanie gdy trzeba aktualizować duże projekty, albo ruch na stronie jest zbyt duży, żeby przy każdym wywołaniu sprawdzać czy jest dany plik i wykonywać następne akcje.

ja jestem za rozwiązniem strife'a, nie koniecznie na git (acz na tym najłatwiej to uzyskać) tylko zrobic branch ktory ma wersje która będzie działać na wszystkich serwisach (ofc zważac na konfiguracje bazy danych bądz innych usług zależnych od serwisu) i odpalic crona ktory co jakis czas bedzie sprawdzał czy repozytorium sie nie zmieniło i sobie updatował, pamiętając o plikach które są zmieniane na każdym serwisie

Można też użyć dropboksa, choć nie wiem do końca czy akurat w tym przypadku.

-- WebNuLL

Nie mam pojęcia co miałeś na myśli, mógłbyś to rozwinąć?

Dropbox to bardziej user-friendly klient SVN. Więc nie ma tutaj chyba sensu o nim rozmawiać. Zwłaszcza, że trzeba udostępniać dane półpublicznie...

Generalnie sprawa wygląda tak, że oprócz tego, że mam bazowy skrypt , to niektórzy klienci życza sobie jakichś określonych zmian. Wtedy trzeba robić pod nich specjalnie nowe pliki /edytować stare.

Patrząc na powyższe, skłaniam się ku SVN. Trunkiem byłby skrypt - baza, pod branchami moi klienci ( każdy na jeden ) - i tam określone zmiany specjalnie dla nich. Tylko nie wiem czy się da zrobić tak, że jak odpalę powiedzmy SVN Update na serwerze produkcyjnym, to najpierw sprawdza czy ma customowe pliik w swoim branchu, jeśli nie to pobiera z trunka, jeśli tak - to z tegoż właśnie brancha?

Jesli tak, to to będzie najprawdopodobniej moja solucja.

Zainteresuj się czymś takim jak springloops.com To jest taki svn z możliwością ustawienia, żeby po commicie robił deploy zmienionych plików na jeden/kilka/kilkanaście serwerów ftp/sftp, których możesz sobie dodawać ile wlezie. Można ustawić żeby na każdy z tych serwerów deploy robił się automatycznie, lub żeby trzeba go było wywołać ręcznie.

Niestety opcja darmowa upoważnia tylko do jednego serwera na który można robić deploy i tylko 3 deploye dziennie

Edit. Każdy dodany deploy ma opcję ustawienia skąd ma pobierać pliki, z jakiego brancha itp..

Odswieżam, może ktoś ma coś do powiedzenia jeszcze.

Aha - niech mnie ktoś oświeci czy da się ustawić SVN jak wyżej powiedziane było.

Da się go tak ustawić, kwestia uruchomienia crona na serwerze klienta i odpowiednich hooks po stronie Twojego serwera. Nigdy tego nie próbowałem, ale admini mojego poprzedniego serwera tak własnie robili dla połowy serwerowni, więc to raczej zadanie typu: "napisz namęcz się, później prześpij się na enterze".