Voglio riportare un link ad un mio vecchio post “Configurare un proxy per Team Foundation Service”, che è stato fatto al tempo della beta di Team Foundation Service, ma che è sempre attuale. Questo post risponde ad una domanda abbastanza comune che viene fatta sul Team Foundation Service, ovvero: “ma poi essendo online ed avendo io una connessione non propriamente velocissima, non è che gli sviluppatori si trovano rallentati nell’usare TFS su Azure?” Il proxy è quindi una soluzione perfetta, che però agisce solamente sul source control, anche se a tutti gli effetti il maggiore traffico di banda che si ha, lo si ha proprio scaricando ed aggiornando sorgenti.

Questo post va a braccetto con “Puntare un build server di TFS ad un Source Control Proxy”, operazione sicuramente doverosa se si installa un Build Server on-premise per effettuare build su un Team Foundation Service. Sebbene infatti le build siano presenti, è presumibile che quando il servizio diverrà RTM ci sarà un certo limite sul numero/Risorse utilizzate. Non è infatti prevedibile che MS lasci gratuita la possibiltà di fare build infinite durante la giornata. Per questa ragione un build server on-premise è la soluzione migliore, e dato che molto spesso le build sono configurate per riscaricare tutto e partire da un workspace pulito, usare un proxy locale con il build server è doveroso.

Buon TFS.

Gian Maria