Categoria: Series

Confira Séries de post técnicos

Git na prática: fazendo merge

Olá Pessoal,

O post de hoje será bem simples e rápido, veremos como fazer merge no git, ou seja, trazer algo que está em um lugar para outro. Por exemplo, de um branch para outro. No git isso é bem simples e rápido.

Lets go…

Starting…

Estarei considerando que seu ambiente está ok, conforme o primeiro post desta série. Vamos usar o mesmo repositório que estamos usando até o momento.

In practice

Lembra que criamos uma branch development e nela fizemos alterações/commit? Então, agora precisamos colocar nossas alterações na master para que outros devs possam ter acesso depois que mandamos para o servidor remoto. Fazer isso com o Git é muito simples, que nem dá para acreditar.  Vejamos :

1      Vamos para o local que queremos que as alterações sejam aplicadas, ou seja, a master

git checkout master

Para garantir que você está na master, verifique git branch

Agora vamos fazer o merge

Então digite

git merge development

Estamos dizendo: me traga todas as modificações da branch development para master. Se tiver algum conflito, é agora que vamos saber.

Merge automático: o git faz merge automático. Mas o que é isso? Simples, um arquivo da branch está diferente do arquivo da master, mas em pontos diferentes o git não considera conflito e consegue resolver as diferenças entre o arquivo.

Merge manual: aqui é quando o git não consegue resolver o conflito entre dois arquivos, pois a alteração aconteceu no mesmo local, daí ele precisa que o desenvolvedor resolva manualmente, ou seja, abrir o arquivo e fazer as alterações.

Veja que não tivemos problema algum e um novo arquivo foi trazido para o master. Nesse caso, o Product.java e nenhum arquivo foi alterado do que já existia.

Veja como ficou o nosso log git log

Vou ficando por  aqui.

See ya!! Abraços.

Série Git na Prática: Trabalhando com branch

Olá Pessoal,

Mais um post da série git na prática. Hoje veremos como trabalhar com branches no git. É tão fácil quanto roubar doce de um recém nascido:  ). Claro que será tudo via linha de comando.

Lets go…

Starting…

Considerando o repositório criado no post anterior, vamos criar uma branch. Mas, pra que?

Bem, o ideal é que você não trabalhe na branch master que é criada no seu primeiro commit pelo Git, e busque usar a master  para fazer push com o seu repositório remoto e seu código em desenvolvimento, coloque em uma branch. Em outras palavras, leve apenas códigos estáveis para o master. Nada impede de você fazer tudo na master, para o git pouco importa isso, o que falei acima é apenas uma sugestão. Talvez se você tiver trabalhando sozinho não vai ver a importância de ter uma branch (mesmo assim eu acho que tem), mas se tiver em equipe verá que é uma mão na roda.

In Practice

Digitando git branch sabemos quais branches temos no nosso repositório

Para criar uma nova branch é bem simples: git branch <nome da branch> então seria

git branch development 

Assim criamos uma branch chamada development e podemos ver a seguir:

O * informa em que branch estamos. Observe que não estamos na development, mas para irmos é bem simples

git checkout development

Assim sabemos onde onde estamos

git status



Sabemos que estamos na branch e nesse caso não há nada para ser committed.

Agora vamos commit arquivos na branch apenas. Portanto criei o arquivo a seguir no repositório:

E vou dizer ao git que esse arquivo vai para branch. Considerando que estou na branch de development, basta:

git add <nome file>

E agora realizar o commit

git commit –m ‘adicionando arquivo na branch’

Verificando alteração na branch

Para verificar se o arquivo realmente foi para branch, vamos ver o log da branch

git log

Observe as alterações feitas na branch. Para conferir que a master não sabe disso, vamos ver o log da master:

git checkout master

git log

Veja que a master nem sabe o que aconteceu na branch.

Simples, não? No próximo post veremos como fazer o merge, ou seja, o que está na branch ir para master.

See ya!!! 

Série Git:Utilizando o GIT via command line Windows

Olá Pessoal,

No post de hoje vamos ver como  usar o git via linha de comando no Windows. Acredito que é a melhor forma de usar o git. Quem vem do SVN e está acostumado com plugins e ferramentas pode se sentir um pouco desconfortável, mas é uma questão de tempo. Apesar de que já há ferramentas GUI para o git disponíveis, porém eu já tive problemas em não conseguir fazer commit ou conectar a repositório remoto etc.

Lets go…

Starting…

Vou considerar que você já tem o git for Windows instalado na máquina, se não tiver, dá uma olhada nos links a seguir e faça a instalação que é super simples:

http://git-scm.com/downloads 

Após ter instalado, é hora de criamos uma pasta que será o nosso repositório no git, no meu caso criei uma para exemplo conforme a seguir:



 

Se você fez a instalação na sua área de trabalho deve ter o git Shell, abra ele para que os comandos do git sejam reconhecidos. Quando instalou o git havia uma opção de pode usar o comando git dentro do prompt do Windows, eu particularmente não gosto, prefiro usar o git Shell, porque ele fica colorido seguindo uma formatação do git e acho que ajuda no dia-dia.

Agora vamos dizer que a pasta que criamos é um repositório git, basta digitarmos git init e uma pasta .git é criada dentro do repositório. Se ela não aparecer no Windows Explorer, veja se as configurações do seu Windows não está para não exibir arquivos ocultos, pois essa pasta é criada como “oculto”.

Vamos adicionar  um arquivo no repositório

 

Agora com os arquivos, vamos ver o status do nosso repositório com git status

 

Observe que o git nos retorna como está o nosso repositório, não há nada para commit. Antes precisamos criar um usuário global para  que possamos identificar de quem foi o commit.

Git config –global user.name “Camilo Lopes”

Git config –global user.email camilo@camilolopes.com.br

 

Fazendo track do arquivo

Agora precisamos dizer ao git para cuidar do track desse arquivo:

git add <nome do arquivo>

 

É isso ai. O pulo do gato é que quando isso acontece o arquivo vai para o INDEX do git, ele ainda não foi comitado, apenas é candidato para ser comitado. E toda vez que o arquivo for modificado, vamos executar esse comando novamente para dizer que ele é candidato para ser comitado. A diferença aqui é que se eu modificar um arquivo e não dar um add para ser candidato ao commit, simplesmente o git ignora o  arquivo modificado e só commit o que é candidate. Percebeu  a diferença?

Depois do INDEX quando o arquivo é comitado vai para o HEAD.

Se executarmos git status agora veremos os arquivos candidate (em verde)

 

Comitando

Para comitar é bem simples git commit –m ‘bla bla’

Somos obrigados a colocar uma mensagem no commit, se não colocar o –m, o git vai abrir uma tela pedindo para informamos. Então não tem como escapar.

Verificando histórico de commit

Agora vamos ver o histórico dos commit

Git log

Nos mostra todo histórico do repositório.

Pronto. Simples, não?

Observe que trabalhamos offline o tempo todo. Uma das vantagens do git.

Vou ficando por aqui…

see ya!! 

Série Agile:Como escrever boas user stories?

Olá Pessoal,

Mais um post, da série Agile e veremos como escrever boas user stories. Este é um ponto importante, pois uma boa user story deve ser entendida tanto pelo team técnico quanto pelo cliente/PO.

Lets…

Sabemos que escrever as user stories, é “trabalho” do PO, mas em teoria, porque na prática quem vai escrever ou é o ScrumMaster ou o time. Nem sempre dá para seguir o que temos na literatura de acordo com a realidade do mercado. Mas o objetivo deste post não é esse e sim tentar responder: “as use stories do seu projeto são boas?” Ou seja, para seu cliente, ela é valiosa? Ele olha para ela e sabe de fato o que significa que será feito?

Lendo o livro JR The samurai Agile (o qual em breve vou publicar um review), em um dos seus capítulos ele aborda sobre o assunto e vi que já cometi alguns erros quando precisei escrever algumas user stories alguns meses atrás em um projeto pessoal. Um dos problemas foi não ter percebido o quanto estava técnico alguns pontos na user story. E o JR fez uma pergunta interessante: “Se seu cliente estivesse com fome e apenas as duas opções abaixo ele teria para escolher, o que é mais claro para ele? “

1. Estória: Ernie’s Tech Diner

  • C++     3 days
  • Connection pooling    2 days
  • Model-View_presenter pattern          5 days

2.Estória: Sam’s Business Pancake House

  • Create user account 3 days
  • Notify subscribers of new listings 2 days
  • Cancel subscription 1 day

Com certeza a estória dois faz mais sentido para o negócio do cliente. Os termos são simples e fáceis de serem entendidos. E o mais comum: quando somos muito técnico é escrever como na primeira estória e SM deve ficar atento com isso caso todo o time esteja participando da escrita das US. E em outro exemplo o JR trouxe que podemos ser técnicos e o cliente entender. A estória abaixo não perde seu valor: 

Add database connection pooling: é dificil para o cliente entender

Mas…

Reduce page load time from 10 secs to 2 secs.

Parece que faz mais sentido para o cliente e você já sabe o que acontece nos bastidores para atingir o objetivo da user story (US).

Enfim, qualquer US deve ser do tipo INVEST, ou seja, independente, negociável, valiosa, estimável, small (pequena) e testável.

  • Independente: sua história não pode depender de outras histórias, caso isso aconteça é preciso quebrá-la.
  • Negociável: é que ela pode ser alterada e adaptada e não fechada.
  • Testável: que seja possível criar testes que valide aquela história. Algo como:

Login with expired:

Testable:

            – redireciona logins expirados

            – mostra mensagens de erros apropriadas

  • Small & Estimatable: não tem que ser grande e sim pequena para que possa ser estimável, quanto maior, mais difícil é estimar.

Vou ficando por aqui, espero que tenham gostado do post.

See ya!

Série Agile: O tester

Olá Pessoal,

No post de hoje vou falar o que os Testers fazem enquanto o time desenvolve. No post anterior falei sobre o conceito de Done, e um dos tópicos para considerar um item concluído tinha que ser qualificado por um tester. Mas, o que o tester faz enquanto não tem nada pronto para ser qualificado? É isso que vamos ver no post de hoje.

Lets go…

E o que o tester faz enquanto o team desenvolve? Vai para Praia?

Antes de mais nada queria reforçar o que eu acredito: todo projeto agile deveria ter no minimo 1 Tester. Falo isso porque vejo alguns comentários na comunidade, às vezes, que com Agile não precisa mais dos Testers. Não sei de onde tiraram isso. Os Testers são membros do time e eles são tão importantes quanto os demais membros (infelizmente há ainda pessoas que olham assim dev X testers), são profissionais que tem uma habilidade de qualificar se aquilo que você fez de fato atende ao requisito do cliente, do contrário ele vai encontrar falhas e vai te direcionar onde resolver. Quando um  Tester pega um bug, não quer dizer que você, Desenvolvedor, é ruim ou no pior, um animal de quatro patas. Não é isso. Eles apenas dizem: “olha, faltou isso”. Porém alguns desenvolvedores não olham assim e se sentem ofendidos. Há vários fatores que contribuem para um bug no sistema, não é apenas questão técnica. Mas isso não entra nesse post, pois é uma longa história :). Mas de fato, o que os Testers fazem enquanto os desenvolvedores ainda estão trabalhando nos itens do Sprint? Vão à praia e voltam daqui uns dias?

Se isso fosse verdade, eu queria ser Tester \o/, mas a resposta é: Não. Eles não vão à praia. Aqui temos uma pilha de trabalho para eles:

  • Montar os use cases de cada item (ou itens) do Sprint backlog etc;
  • Preparar o ambiente de teste (homologação);
  • Interagir com o team, tirando dúvidas dos itens;
  • Sincronizar informações com o product owner.

Tudo isso consome tempo e é bom ter tudo pronto antes do primeiro item ficar pronto. Os Testers participam das reuniões diárias (afinal de contas ele é membro do time), do planning, então nada melhor que já ir montando os testes seguindo a ordem de prioridade dos itens que foi definido pelo PO.

É preciso adicionar um item no quadro de task para o Tester e ir acompanhando as atividades dele durante as daily meeting?

Não ou Sim. Eu acredito que não, na primeira Sprint eu não faria isso e talvez na próxima sim, como tudo é um aprendizado, vamos ver o que podemos aprender no Sprint 1 com esta abordagem. O motivo de não querer adotar um item exclusivo para o tester é por realmente não achar necessário, exceto se o PO colocasse isso no product backlog, onde acredito que ele não fará isso, porque o PO não está muito interessado no “como” será feito ou qualificado, desde que atenda aos critérios de qualidade e requisitos de negócios estabelecido por ele.  Uma forma seria adicionar uma task a cada item do tipo “preparação para teste” e em uma das daily meeting o desenvolvedor iria dizer: “olha, hoje termino o desenvolvimento e amanhã já tenho o item pronto para ser qualificado”. Então o tester já pegaria a task, colocaria  na coluna de “in progress” e dizendo “tá,eu vou começar a preparar o ambiente hoje e amanhã as X horas posso iniciar a validação”.  Essa foi uma abordagem que achei válida e bem prática até o momento, pois consegui manter a iteratividade entre tester e desenvolvedores em um projeto que participei no mês passado.

E você, como lida com esse cenário? Compartilhe sua experiência :).

Vou ficando por aqui e espero que tenham gostado do post.

Abraços, see ya!