Definitywny koniec FTP

Dzisiaj podczas pracy nad projektem dla jednego z moich klientów w końcu dotarła do mnie myśl – definitywny koniec z FTP. Nie będę już używał tego protokołu nawet do małych zleceń bo to po prostu zwykła strata czasu, pieniędzy i nerwów.

Mam serwer wykupiony w Polskiej firmie za niewielkie pieniądze, który oferuje mi przestrzeń dyskową, pocztę elektroniczną, cpanel, webmail i wszystko co tylko oferują dostawcy hostingów. Dla kogoś kto chce prowadzić blog i od czasu do czasu modyfikować kod jest to bardzo dobre rozwiązanie. Można tam poprzez pare kliknięć zainstalować WordPress i zacząć publikować treści. Pliki można ta wgrywać na dwa sposoby:

  1. Poprzez „Przeglądarkę plików” dostępną z cpanel.
  2. Poprzez FTP

Przeglądarka jak sama nazwa wskazuje nadaje się do przegladania. Podmiana 2-3 plików nie stwarza jeszcze problemu ale podmiana całej zawartości stron jest po prostu niemożliwa ze względu na ograniczenia co do wielkości przesyłanych plików.

Wrzucanie przez FTP jest więc jedyną możliwą formą wrzucenia całości. Zawsze przy rozpoczynaniu pracy nad projektem tworzę sobie repozytorium GIT po czym zaczynam programowanie. W miarę rozrastania się projektu pojawiają się błędy, które trzeba poprawić, kompletne zmiany funkcjonalności, która już jest i działa poprawnie ale klient zażyczył sobie żeby jednak działało inaczej i różne inne sytuacje kiedy trzeba szybko zmienić kod i wrzucić go na serwer. Sytuacje takie zazwyczaj kończą się tym że kod zostaje wrzucony tylko na serwer a nie do repozytorium i cała koncepcja używania systemu kontroli wersji przestaje mieś sens.

Innym przypadkiem kiedy FTP nie sprawdza się są migracje bazy danych. Kiedy nie ma dostępu do serwera przez ssh trzeba napisać sobie brzydki dostęp do tej funkcjonalności przez web. Można co prawda używać jednego framework’a, do którego już kiedyś napisaliśmy system migracji i w takim przypadku strata czasu na napisanie koła od nowa jest jednorazowa ale spotkałem się z przypadkiem gdy dostęp do systemu migracji dostępny był albo poprzez dwudniowe studiowanie kodu w celu uruchomienia aplikacji konsolowej przez web albo przez używanie brzydkiego wywołania bash’a z poziomu kodu. Jak się okazało później serwer nie pozwalał na wykonywanie bash’a a ja nie miałem dwóch dni przez co migracje odbywały się poprzez kopiowanie logów z lokalnej bazy do phpMyAdmin.

Najmniej uciążliwa dla mnie ale za to najbardziej uciążliwa dla klientów jet sytuacja kiedy na serwer wrzuci się coś co wrzucić się nie miało. Moim obowiązkiem jest to żeby nie doszło do takiej sytuacji jednak kiedy przyzwyczaimy się do pracy z systemem kontroli wersji i przychodzi nam do używania FTP gdzie jedynym sensownym rozwiązaniem wrzucania zmienionego kodu jest przekopiowanie wszystkiego z lokalnego środowiska na serwer zdarzają się sytuacje kiedy wrzuci się coś co wrzucić się nie miało. Przykładem takiej sytuacji jest upload lokalnego pliku konfiguracyjnego i pójście spać. Rano okazuje się że cała strona padła bo w pliku było połączenie do lokalnej bazy danych.

Rozwiązaniem jest używanie serwera z dostępem przez ssh a najlepiej VPS. Ja zacząłem używać AWS i jestem bardzo zadowolony. Teraz kod wgrywam poprzez `git pull` i jestem pewien że wszystko będzie działało jak należy. Dodatkowo żeby wrzucić coś na serwer muszę to commit’ować co skutkuje porządną historią zmian. I nie ma już sytuacji podmiany pliku lokalnego bo takie pliki po prostu dodane są do .gitignore. Migrowanie bazy też nie przysparza żadnych  problemów bo mogę korzystać z CLI.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *