DevOps, por Brian Guthrie

https://twitter.com/bguthrie/status/935260873316274179 Este post é a tradução dos tuítes de Brian Guthrie sobre DevOps. Hoje, vou fazer uma reclamação sobre o termo DevOps. Juntem-se a mim, amigos! Aqui vai: o termo DevOps originalmente tinha um significado completamente diferente de como é entendido atualmente, e eu gostaria de falar um pouco sobre por que isso importa, e … Continue lendo DevOps, por Brian Guthrie

Anúncios

Como Priorizar Funcionalidades

É incrível como ficamos criativos quando estamos discutindo ideias para um produto de software. A quantidade de funcionalidades que poderíamos adicionar ao backlog certamente tomaria todo o quadro. Existem formas bem interessantes de limitar as funcionalidades para obter um produto que estimule mais os usuários. Mas nem sempre é fácil remover funcionalidades da lista. Portanto, o melhor que podemos fazer é separar as mais importantes para fazer primeiro, e ir descobrindo com o tempo se as outras funcionalidades permanecem interessantes.

Git Model

Um Modelo Bem Sucedido para Ramificações no Git

O texto original em inglês[1], de Vincent Driessen, pode ser encontrado no endereço: http://nvie.com/posts/a-successful-git-branching-model/ Neste post, eu apresento o modelo de desenvolvimento que introduzi em alguns projetos (no trabalho e privados) há cerca de um ano, e que acabou se mostrando bem sucedido. Gostaria de ter escrito há mais tempo, mas não achei um tempo até … Continue lendo Um Modelo Bem Sucedido para Ramificações no Git

Infraestrutura na Nuvem – não dê nome aos bois

Era uma vez um programador de DAOs. Dionatan tinha conseguido essa honrada posição no Projeto Quéops depois de um ano como "programador júnior", cuja principal atividade era programar "getters, setters e toStrings". O antigo programador de DAOs saiu da empresa e, amigo de Dionatan, recomendou-o por ser confiável o suficiente para mexer com os acessos ao banco. Dionatan recebia uma "Java Interface", provavelmente do cara do cubículo ao lado, que também fez o DAO Factory (e inúmeras outras "factories") seguindo as recomendações do Todo-Poderoso arquiteto. Dionatan não sabia o nome do homem-factory e do Todo-Poderoso, porque trocavam as pessoas com frequência. Com a "Java Interface", bastava criar uma implementação e preencher os métodos. Várias vezes, era só copiar boa parte do que o amigo já tinha deixado pronto e mudar alguns nomes.

Quebrando um software monolito: Microsserviços vs. Sistemas Autocontidos

Texto de Olga Annenko, disponível em: http://www.elastic.io/breaking-down-monolith-microservices-and-self-contained-systems/ As publicações e discussões recentes de TI estão cheias de termos como "transformação digital", "TI bimodal", "desenvolvimento contínuo" e "agilidade". Não há necessidade de discutir que arquiteturas monolíticas e aplicações monolíticas devem se tornar coisas do passado, cedo ou tarde - de preferência, cedo, é claro. E de fato os departamentos de TI são encorajadas a se afastar dos monolitos por causa de inúmeras razões perceptíveis e compreensíveis: manutenção complicada, muitas dependências, dificuldades de teste e implantação (o monolito só pode ser implantado como um todo.) Os monolitos são como o Triângulo das Bermudas para qualquer iniciativa ágil de TI.