SVN i zarządzanie wersjami (cykl pracy)

Przy okazji ostatniego projektu udało nam się wypracować dobrze spisujący się proces wgrywania poprawek do działających serwisów. Chciałbym się nim z Wami podzielić...

Oczywiście korzystamy z SVN'a na jego mechanizmach ten proces został oparty.
Zasada jest dość prosta: kolejne działające wersje to tagi. A żeby kopię roboczą ustawić na nowy tag wykonujemy tak zwany switch.

Jedynym problemem była kwestia poprawek, które należy na przykład wprowadzić bezpośrednio w prodykcyjnej wersji systemu. Pomysł, aby każdą taką poprawkę wprowadzić najpierw do repozytorium, a następnie update wersji jest zbyt kosztowny. Z kolei wprowadzenie tych poprawek na wersji produkcyjnej często owocował wieloma konfliktami, które są bardzo nieporządane z uwagi na to, że serwis jest ogólnodostępny i priorytetem jest jego dostępność.

Rozwiązaniem jest następująca zasada:
Możesz zawsze dokonać poprawki na wersji produkcyjnej. Jednak, żeby poprawka była trwała - musi być niezależnie wprowadzona do repozytorium (commit do trunk). Poprawki dokonane tylko w produkcyjnej kopii roboczej zostaną najprawdopodobniej utracone przy następnym uaktualnieniu.

W takim wypadku przed switch'em wystarczy wykonać polecenie revert, np
svn revert ./ && svn sw https://moje.repozytorium.com/tags/beta-1
Lokalne zmiany są wycofywane, a kopia robocza zostaje przełączona na wersję beta-1.

W takim podejściu do problemu update'y zajmują od 3 do 10 minut, co jest akceptowalne.

HttpSocket z cake 1.2 w cake 1.1.x

Jeśli potrzebujesz funkcjonalności zapewnianej przez HttpSocket(na przykład musisz pracować na danych w xml-u dostarczanych choćby przez kanał rss), a z jakichś powodów nie możesz korzystać/migrować na CakePhp1.2, zastosuj poniższą sztuczkę:

Z biblioteki CakePhp1.2 (cake/libs/) do katalogu vendors w Twojej aplikacji (1.1.x) skopiuj pliki
- socket.php
- http_socket.php

W pliku socket.php gdzieś na początku, przed definicją klasy jest linia
uses('validation');
zakomentuj ją (lub usuń) .
Z kolei w pliku http_socket.php linię
uses( 'socket', 'set');
Zamień na
vendor('socket');
uses('set');

Sposób działający pomiedzy wersją 1.2.0.6311 beta a 1.1.16.5421.
Powodzenia

Jak korzystać z requestAction w CakePHP

Ta bardzo przydatna funkcja nie jest zbyt dobrze opisana w dokumentacji, dlatego pozwolę sobie ją tu opisać.

Object::requestAction(string $url, array $extra);
Służy do łatwego wywoływania funkcji z jednego kontrolera w innym kontrolerze. Sprawa jest prosta, jeżeli wywoływana funkcja potrzebuje jedynie parametrów, które możemy przekazać w url-u (/posts/show/1).
Jednak sprawa komplikuje się, kiedy potrzebna metoda korzysta z danych przesłanych w formularzu. Komplikuje się o tyle, że w wyniku ubogiej dokumentacji, trudno odgadnąć czy jest to możliwe.
Jednak m.in. po to jest parametr $extra. Jeśli wasz kontroler czeka na dane z formularza ['User']['username'] i ['User']['password'], to można je "wcisnąć" do kontrolera poprzez requestAction w następujący sposób:

$data['data'][['User'] = array('username'=> 'ala', 'password' => 'makota');
$this->requestAction('/users/login', $data);

Dzięki tej sztuczce uda Ci się ominąć kilka sytuacji, w których wcześniej pisalibyście osobną funkcję.

Ps. Cake jest pełen takich nieudokumentowanych niespodzianek, które czekają na odkrycie - zachęcam do eksperymentów.
Pps. Szczególnie przydatność requestAction odczujesz, kiedy zaczniesz intensywniej korzystać z pluginów w CakePhp.

"Sprytny" redirect (cakePHP 1.2)

Załóżmy, że mamy mały system bloga (posty + komentarze).
Cake upiekł za nas widoki i metody. No i powiedzmy, że teraz w post/view/[id_posta] chcesz umieścić możliwość dodania komentarza. Oczywiście tworzysz formularz, którego action='/comments/add' i w CommentsController::add() wpisujesz na sztywno (hard-coding) $this->redirect('/posts/view/'.$comment['post_id']).

Wszystko pięknie i ładnie działa, ale powiedzmy teraz chciałbyś w widoku posts/list_all, w którym wyświetlasz skrócone wersje wszystkich postów dać możliwość szybkiego dodania komentarza. No i znów pakujesz do środka formularz z action='/comments/add' i fajnie działa, ale redirect jest do jakiegoś jednego konkretnego posta, a nie listy w której szanowny user kliknął 'submit'. Niby nic złego się nie dzieje, ale szanowny user odczuwa dyskomfort, jest wręcz zagubiony.

Ostatnio wymyśliłem i z powodzeniem zastosowałem mały trik, który ten problem rozwiązuje w sposób uniwersalny i (w miarę) elegancki.
Zazwyczaj, jeśli tworzę formularz do innego kontrolera, to najczęściej wtedy wiem, gdzie po przerobieniu tych danych powinien się odbyć redirect... najczęściej z powrotem. Zatem preparuję parametr action w następujący sposób:

action=<?php echo $html->url('/comments/add') ?>?r=/posts/list_all/"

A w AppController

    function beforeRender(){        if(isset($this->params['url']['r'])){             $this->redirect($this->params['url']['r']);          }     }

Prosta metoda, która zawsze sprawdzi mi czy przekazałem informację o przekierowaniu i w razie czego ustawi odpowiedni adres przekierowania. Nie muszę pamiętać o tym w każdej metodzie, w której jest prawdopodobne, że będę chciał zrobić redirect w różne miejsca. Po prostu implementuję to na początku projektu i cieszę się kolejnymi zaoszczędzonymi minutami :D

Smacznych jajec ;)