Estou em um projeto onde todo o trabalho entra via pull requests.

Em posts anteriores, reforço que um administrador de um servidor, de rede, e também do TFS / VSTS, deve saber usar o console, deve saber usar Powershell, na stack Microsoft, e futuramento no Linux, mas neste último existe a opção do bash também.

Um bom administrador de um serviço hoje em TI usa console! A UI é importante, funciona para pequenas coisas, mas quando se precisa de automação, ou executar lotes de alterações, nada melhor que o bom e velho console.

No post Administração de usuários e grupos no TFS/VSTS, foi descrito o funcionamento do cadastro de usuários e grupos.

Semana passada escrevi sobre a mudança de tasks para steps, a arquitetura de build foi totalmente alterada; portanto o que se sabia para escrever na estrutura de uma definição de build não é mais válido.

Licenciamento de software pago é tão complicado quanto as licenças de software livre, sim elas existem e é preciso dedicar um tempo para entender qual a licença correta para o uso que você está dedicando ou se você está utilizando um software livre da maneira correta.

O TFS, sempre comparado a um simples versionador de código fonte, sempre vejo perguntas do tipo “qual a vantagem  do TFS em relação ao SVN?”; tem uma importante parte negligenciada constantemente por empresas que não possuem um bom processo de ALM: build.

Semana passada fiz um post sobre o comando git clean, que faz uma limpeza na sua pasta de trabalho, eliminando arquivos de compilação, bin, obj, para .

tl;dr: Se você é administrador de um pequeno time e restringir acessos não é algo importante para você, adicione os desenvolvedores conforme imagens abaixo, … para todos os outros cenários, continue lendo este post! 🙂

Toda vez que o time de ALM da Lambda3 vai começar um novo projeto em algum cliente, fazemos uma reunião de kickoff para organizarmos nosso projeto.