DevOps

Hoje eu estive lendo este excelente artigo que o Felipe Reis escreveu pela IBM: https://www.ibm.com/developerworks/community/blogs/rationalbrasil/entry/o_que_devops?lang=en

Em resumo, ele explica esse novo conceito de desenvolvimento DevOps. Mais uma vez, este é um modelo já conhecido e utilizado por empresas do Vale do Silício e que é novidade por aqui. Diferente do que dizem alguns sites o DevOps não e só: uma ferramenta, uma cultura http://theagileadmin.com/what-is-devops/, mas sim um modelo a ser aplicado sobre o processo de desenvolvimento de projetos como o Flickr e o Facebook para diminuir o tempo de entrega de suas atualizações.

O DevOps, termo originado pela junção de Developers and Operations(Dev + Ops), tem foco na eliminação dos gaps na transição entre a elaboração e entrega do produto. Através do uso deste método é possível “padronizar” o modo dessa transição e assim conduzir à entrega do produto cada vez mais rápida. O conceito surgiu em meados do ano 2008, por interesse de operadores de infra (ex.:Patrick Debois) em integrar valores da metodologia ágil à operação da infraestrutura [lista agile-sysamin]. Em 2009 Patrick Debois se inspirou em uma palestra que assistiu onde foi apresentado o case da Flickr: 10 Deploys per day at Flickr: Dev and Ops colaboration.

O DevOps também não deve ser confundido com Desenvolvimento Ágil. Ambos podem trabalhar juntos em um mesmo processo de desenvolvimento de software, isso porque o DevOps aproxima as equipes/atividades de Desenvolvimento e Operações enquanto  o Desenvolvimento Ágil aproxima as equipes/atividades de Negócios e Desenvolvimento. O DevOps também tem o papel de apoiar o Desenvolvimento Ágil, pois de nada adianta tornar a produção do software mais rápida se não for possível entregá-lo ao cliente mais rápido também. Veja a figura abaixo para entender melhor a diferença entre eles.

devopsBom.. e como é o DevOps funciona? Apesar de não ser uma técnica de Desenvolvimento Ágil, o DevOps compartilha de algumas premissas definidas no Manifesto Ágil. Uma das suas funções é fazer com o que o deploy seja automático para que assim toda a cadeia do processo fique otimizada. Veja a figura a seguir. 

devOps_autoMas isto só cumpre o lado Ops do DevOps. É necessário que o lado Dev também ganhe autonomia para executar também atividades de deploy, controle de versão, gerência de configuração e orquestração. Desta forma, a equipe passa a ser multidisciplinar, assim como ocorre para o modelo de Desenvolvimento Ágil.

As principais tópicos relacionados ao modelo DevOps são:

  • Valores = Basicamente, manter o software funcionando. O serviço ganha maior atenção;
  • Princípios = Pessoas e processo primeiro; Confiança, respeito, sinceridade, honestidade, comunicação efetiva, postura construtiva, entre a equipe; Infraestrutura como código; Ambiente de entrega contínua; Simplicidade e automatização do processo;
  • Métodos = SCRUM, Kanban, QA, entre outros;
  • Práticas = Aplicação de TDD; Integração contínua; Deploy contínuo; Esquemas de monitoração; Controle de métricas; Uso de virtualização e cloud computing;
  • Ferramentas = O uso é livre. As mais conhecidas são: Jerkins, Travis, Teamcity para a Integração Contínua; Puppet, Chef, Ansible, Cfengine para Gerência de Configuração; Zookeeper, Noah, Mesos para Orquestração; AWS, OpenStack, vagrant, docker para Monitoraçaõ e Virtualização; entre outras ferramentas e categorias.

Outras referências: http://pt.slideshare.net/GutoCarvalho/devops-26412358?next_slideshow=1
http://www.getchef.com/blog/2010/07/16/what-devops-means-to-me/
http://www.kartar.net/2010/02/what-devops-means-to-me/

Como fazer levantamento dos Cenários de Teste

Quando você vai criar casos de testes é necessário seguir o plano de testes e estratégias definidas anteriormente. Feito isso, você vai precisar realizar alguma forma de estimativa (qtd. cenários/funcionalidade) e então definir os cenários que devem ser escritos para cobrir as funcionalidades da página, módulo ou um fluxo de operação dentro de um sistema.

Aguarde, em breve lançarei vídeo-aulas sobre como escrever casos de testes manuais e automatizados ;).

Uma boa prática, antes de escrever os casos de testes é realizar o levantamento dos cenários. Você deve fazer isso para ter a real dimensão da funcionalidade que deve ser coberta pelos testes e para guiar a própria escrita dos cenários. Dito isto, será necessário avaliar cada requisito das especificações para traçar os tais cenários.

E você vai poder fazer o levantamento desta forma:

  1. Isolar um requisito da especificação (ex.: o botão deve mudar de cor ao ser clicado);
  2. Observar ação e resultado. Um cenário deve ter um objetivo (ex.: mudar a cor do botão) e por isso é importante que ele possua uma ação e resultado para ação. (ex.: ação: clicar no botão / resultado: mudança da cor do botão);
  3. Descrever o objetivo do cenário (ex.: mudar a cor do botão) e partir para definir outro cenário.

Você só vai precisar escrever o objetivo dos cenários. Posteriormente ele servirá de contexto para a escrita dos passos dos cenários. E você pode escrever isso na própria ferramenta de gerência de testes (QC, TestLink, outras) ou em um simples bloco de notas, planilha, etc.

Essa simples ação de realizar o levantamento dos cenários vai te ajudar a: economizar tempo, organizar a escrita dos cenários, a não fugir do contexto do teste, a não esquecer de cobrir os requisitos requeridos e servirá de partida para a escrita dos próprios cenários.

Veja um pequeno exemplo que fiz na ferramenta Calc do BrOffice:

levantamento_cenarios

Até mais! 🙂

O problema do Update @form

Galerinha,

Quando atuei em um ambiente Java + JSF + Rich/Prime Faces eu peguei vários bugs que aparentemente eram fáceis de serem corrigidos. Foi o caso do: check-box que não marcava depois de desmarcar, o textbox que não limpava seu conteúdo após voltar para a tela, e até mesmo a página que não direcionava para outra ao salvar um registro, coisas básicas e consideradas fáceis de se resolver.

O problema é ter de lidar com os componentes dinâmicos da sua página com integração Rich/Prime Faces. Mas isso, nem eu, nem meus colegas sabíamos e por isso levava horas para corrigir esses pequenos problemas. Debugava o código, escrevia novos métodos, ia mexendo em cada camada da aplicação para entender e isolar onde estava o erro.

Mas você não vai precisar passar por isso… aí vai a dica:  quando você precisar dar um Update no seu form JSF que possua vários componentes dinâmicos, ou quando você for precisar trabalhar com ajax em cima dessa estrutura, nunca escolha a opção @form. O update form serve para reenviar todos os dados e ações de todos os componentes da página, de uma só vez ao seu Managed Bean, quando ele é utilizado. Com isso, os dados que precisavam ser mantidos no Managed Bean são perdidos e os componentes ajax(rich e prime faces)/com javascript/jQuery embutidos, param de funcionar.

update_form

Opte sempre por dividir os componentes ou grupos de componentes da sua página dinâmica por grids ou painels. E daí você pode fazer o update em cima deles. Basta inserir um id para cada um deles e começar a manipular o conteúdo do update com base neles. Isso é até mesmo uma boa prática, porque você vai ter maior controle dos seus componentes e o seu Managed Bean não vai mais ser inundado com os dados de todo o formulário a cada ação realizada pelo cliente sobre a página. 😉

update_local

PS.: Em casos de páginas contendo múltiplos componentes com conteúdo dinâmico, para redirecionar a página, você vai precisar inserir um grid ou um panel em toda a sua página e dar o update em cima dele, ok?

Conhece outra forma de resolver isso? Comente, por favor!!

Help me!

Hoje, o mercado de TI requere e os colegas de profissão reconhecem a importância em ter um bom nível de entendimento da língua inglesa. Isso porque muitos dos materiais disponibilizados pela comunidade de software são escritos em inglês.

Vejo o estudo do inglês como um ponto de crescimento pessoal. Ler, escrever, falar e principalmente entender o que se fala em inglês, além de ser uma vantagem profissional é uma forma de expandir networking e disseminar cultura.

Por conta disso eu criei este novo espaço. Quero discutir com vocês as formas com que cada um acha mais fácil se comunicar em inglês e promover a conversação entre nós.

logo_help_me

Help me! Write here with me in English, please! 😉

Inclusão SW

Pessoal,

Estou criando um espaço a mais no meu blog para acolher àquelas pessoas que não sejam área de TI, mas que têm curiosidade pela área, como é o caso do meu vizinho, pai querido de um amigo meu. Bom.. caso tenham dúvida a respeito de algum tema básico assunto, expressão utilizada na área de desenvolvimento de software, comenta aí!

 

ATENÇÃO: Eu não sei de Tudo, é claro, eu não sou Deus! uaahuh Mas eu prometo que vou fazer de tudo para buscar uma explicação para o porquê de o seu problema/dúvida, caso eu não saiba responder. Vamos juntos caminhar para evoluir, blz?

 

logo_inclusao_sw

Abçs e obrigada! 🙂

SOS TCC

Galerinha,

Muito se tem comentado atualmente sobre a validade dos títulos acadêmicos para os profissionais que desenvolvem software. É muito verdade que o modelo de educação utilizado até o momento é arcaico e precisa passar por mudanças para que realmente contribua na formação das pessoas.

Agora, para quem vive fora do contexto Rio-São Paulo, onde estão instaladas algumas empresas de ponta, multinacionais e fábricas de software que implementam uma visão de mercado e estilo mais aberta, fica quase inviável conquistar uma boa colocação no mercado sem contar com os títulos.

Eu venho de uma educação formal, fiz faculdade e atualmente curso pós-graduação, tudo no campo da computação. Eu particulamente não acho inválido ou desmereço os créditos que adquiri ao cursá-los. Vejo isso também pelo imenso esforço empenhado pelos meus queridos professores (IFBa), que são linhas fora da curva, para eu conseguir tirar esta vantagem. Mesmo assim, penso que é necessário sempre buscar evoluir, seja de qual forma for. Você só precisa buscar o modelo que lhe é mais fácil atender ou mais confortável. Isso vai de cada um.

Bom… pensando naqueles, que como eu, optaram por seguir a linha tradicional e por isso têm a árdua tarefa de enfrentar o Trabalho de Conclusão de Curso (Escrita de : monografia, artigo, projeto, etc.), eu estou criando um cantinho a mais no meu blog.

O SOS TCC é um espaço para a discussão de ideias, métodos, troca de dicas e sugestões a respeito dos trabalhos de conclusão que envolvam o campo de software ou não. Essa ideia surgiu porque percebi que alguns de meus colegas (trabalho/faculdade/amigos pessoais) ficam travados nesta fase do curso. Tenho acompanhado de perto dois casos e por isso também empenho esse esforço na ajuda desses dois amigos do peito.

logo_sos_tcc_

Te convido a compartilhar suas dificuldades, aspirações, ansiedades (pq rola mta, mas mta mesmo uahauh) e a crescer junto comigo. Basta comentar logo abaixo e trocaremos cartas e figurinhas ;).

PS: no momento eu estou escrevendo TCC para a conclusão da pós rs! 😛

Abçs e Até mais meu povo querido! 🙂

CONADEV 2015

Galera,

Fiquem ligados no evento CONADEV 2015.

O Conadev 2014 acabou de acontecer e foi muito legal! Ele foi gratuito e contou com palestras diversas sobre desenvolvimento de software e empreendedorismo. Os palestrantes, nomes já conhecidos ,  mudaram a minha visão a respeito de arquitetura de software, métodos ágil e outros assuntos.

Veja mais detalhes e acompanhe o evento no site: http://www.conadev.com/

Dica bônus: assista ao mega-hangout do conadev neste link – https://www.youtube.com/watch?v=0KyednM2pGQ

Fica aí o meu obrigada ao Jansen e ao Rafael. Até ano que vem meninos! \o/