Esta é uma página incremental, ou seja, a contribuição via comentários é bem vinda. Novos requerimentos podem ser adicionados no formato de user stories, no formato:

Como < competência >, < ação/ desejo >.

Requerimentos ( User Stories )

• Como usuário comum, ter acesso a questões frequentes e documentação de procedimentos técnicos relacionados aos serviços NUTEAD.


• Como usuário colaborador, ter acesso a questões frequentes, a documentação de procedimentos relatos a serviços, e a manutenção de serviços.


• Como usuário colaborador, poder acrescentar informações a base de conhecimento, passando por revisão antes da publicação.


• Como usuário editor, ter todos os privilégios anteriores, editar todo conteúdo já gerado, e ter acesso a documentos privados sensíveis a administração dos serviços internos.


• Como usuário administrador, ter total controle sobre a informação, usuários e manutenção da ferramenta.

Arquitetura de Desenvolvimento

O processo de desenvolvimento do suporte.nutead.org, basea-se no processo conhecido como git flow[1], para a estrutura de branches:



Novos Plugins e Themes, devem ser desenvolvidos em feature branches individuais.

Feature Branches

 

Quando deseja-se desenvolver um novo recurso, seja ele um pluging ou theme, deve ser criado um brach específico para esta tarefa, com o objetivo de não colidir com alguma modificação emergencial, que também deve ser tratada com um branch específico, no caso um hotfix branch.

#Deseja-se desenvolver um plugin para listagem de polos, chamaremos este de "listpolos".

#Crie o novo feature branch no repositório remoto

git push origin master:refs/heads/feature-listpolos



#Sempre esteja atualizado com o repositório

git fetch origin



#Crie o feature branch no ambiente local, de modo que acompanhe o branch remoto

git branch --track feature-listpolos origin/feature-branch



#Acesse o novo branch e comece a codar

git checkout feature-listpolos

Uma vez concluído o novo recurso, deseja-se incluir o mesmo aos branches de ‘develop’ e/ou ‘master’, porem por questões de boas praticas devemos manter o histórico do sistema sempre linear, para garantir isso basta efetuar um merge do branch a ser integrado, e então um merge no branch integrador.

git merge master

git checkout master

git merge listpolos

 Deploy a partir do Master branch

 

Uma grande vantagem no uso o controle de versão GIT, é a possibilidade e facilidade no processo de deploy de aplicações.Em nossa arquitetura, novas releases são enviadas para um servidor de staging a partir do branch de ‘release’ enquanto passam por homologação, e posteriormente para o servidor de produção a partir do banch ‘master’.

#Acessa o branch de release

git checkout release



#Garante que local e remote estejam atualizados

git pull origin release



#Combina o branch develop com release

git merge develop



#Devolve as atualizações ao servidor de staging

git push origin release

 

Instalação

 

Git remoto

Nomenclatura

• staging- repositório remoto interno de testes e homologação. Quando clonado a partir de staging ele será chamado de ‘origin’ por padrão no repositório local, para tanto use:
  

  git remote rename origin staging

  
  


•  production – repositório de produção, com apenas o branch ‘master’.

Instalação

No servidor remoto, ‘staging’ ou ‘production’

apt-get install git-core

 

Usuário Git

adduser git

Definir uma chave ssh [3]

su git

cd /home/git

mkdir .ssh

chmod 700 .ssh

cd .ssh

ssh-keygen -t rsa -C "git@nutead.com"

Novo Projeto

cd /dados/sites/www

mkdir suporte

cd suporte

git init

 

Instalação WordPress local via Git

mkdir suporte

cd suporte

git init

git pull https://github.com/WordPress/WordPress.git 3.2-branch

git add .

git commit -m "incluído o core do WordPress'



#adiciona o repositório remoto 'staging', projeto 'suporte'

git add remote staging ssh://git@nutead17.nutead.org/dados/sites/www/suporte



#envia código atual ao repositório 'staging'

git push staging master

Atualizando WordPress com Git

Acessa o subrepositório…

cd wordpress

git fetch --tags

git checkout 3.3.2

Substituindo “3.3.2? pelo valor da tag estável e mais atual, para então retornar ao repositório do projeto e efetuar o commit das mudanças.

cd ..

git commit -m "Atualizado WordPress p/ v3.3.2"

 

 

Aplicações

• Serviço Suporte Nutead  (suporte.nutead.org)

 

Referências

• [1] http://nvie.com/posts/a-successful-git-branching-model/


• [2] http://blip.tv/akitaonrails/screencast-come-ando-com-git-6074964


• [3] http://help.github.com/linux-set-up-git/

cd wordpress git fetch --tags git checkout 3.3.2