Many teams are excited to start using Kubernetes. Some are interested in the resilience, elasticity, portability, reliability and other advantages Kubernetes offers natively. Some are technology enthusiasts and just want an opportunity to work with this platform, to get to know more about it. Some developers want to acquire experience with it, so they can add another highly demanded skill to their resumé. In general, most developers these days want to work with Kubernetes at some point.
That may be a really good idea and it may not.
As defined by the official documentation website,
“Kubernetes provides you with a framework to run distributed systems resiliently. It takes care of scaling and failover for your application, provides deployment patterns, and more.” …
A arquitetura em Microsserviços ganhou popularidade nos últimos anos, porém envolve muito mais do que criar e manter uma solução composta de diversos “micro” serviços.
Em primeiro lugar, quando que uma abordagem distribuída passa a ser mais adequada que uma abordagem monolítica? Que critérios utilizar para isolar e distribuir serviços? Quais os impactos ao adotar uma estratégia distribuída em detrimento da estratégia monolítica?
Para responder as perguntas acima, iremos entender como e por quê aplicar o mindset do Domain Driven Design na refatoração de uma solução monolítica em uma solução distribuída, desfazendo-nos de alguns preconceitos comumente pregados no mercado e tendo ciência dos desafios que essa abordagem trará no desenvolvimento, testes, entrega e manutenção da solução. …
After a while I’ve published the “The best branching model to work with Git”, I noticed that even if the branch strategy is well defined, its connection to the delivery pipeline may still be unclear.
Some of the questions I’ve heard are:
In this post, I’ll review the concepts of Continuous Integration, Continuous Delivery and Continuous Deployment, reinforce some branching principles and connect these concepts with the most suitable approach of delivering model. …
Recently a customer asked me a very interesting question about DevOps. My team is supporting his company through a digital transformation process started by the development department, and he works on the infrastructure department.
He and his colleagues got interested in this “modern way of working”, and they’re doing the best they can to fit in. Despite their efforts, the velocity to change or provide new infrastructure is frequently seen as a bottleneck to the development.
He asked: how can the Operations team be Agile too?
He may have thought that his team could implement Scrum as the developers did, and his team would be more engaged with their tasks and deliver faster. …
A lot of people ask me about Branching Models, which starts a nearly philosophical discussion: which is the best model with Git?
Git is the de facto version control system. It is the most accepted by the technological community, and one interesting fact is that even Microsoft, that created the TFVC (Team Foundation Version Control), encourages to use Git:
Git is the default version control provider for new projects. You should use Git for version control in your projects unless you have a specific need for centralized version control features in TFVC. — Comparison Git vs TFVC
Before we talk about branching strategies using Git, it is important to understand the basics of Git version control. I see a lot of people that uses IDE’s and visual tools to do the basic operations like commit and push changes, create and merge branches, compare history and revert changes, without learning how Git actually works. It can be enough at some scenarios, but to be able to decide which branching model is best for your team, deep dive into the Git documentation. It has some nice tutorials, like the Git User Manual if you want to get started, and the Git Cheat Sheet, if you already know the basics and want a quick overview of the most common commands. …
In order to demonstrate the features of TFS, I use the ALM Virtual Machine from Brian Keller, designed for the Microsoft Hands on Labs of TFS.
It’s a virtual machine pre-installed with Visual Studio Enterprise 2017 (15.5), Visual Studio Team Foundation Server 2018, Office and pre-configured with sample projects, users and data.
You can download the VM as instructed here and configure it as instructed here. It’s a 18 GB download, you’ll need Hyper-V enabled and a minimun of 8GB of RAM available for use.
After it’s configured, I edit my hosts file for making it easier to access the TFS Portal on the host machine. I configured a Virtual Switch between the host and the VM on Hyper-V Virtual Switch Manager, and then selected it on the Network Adapter settings of the VM. Then I identified the IP Address and included it on the hosts file on the C:\Windows\System32\drivers\etc folder. …
No meu artigo anterior, “Desmistificando o DDD”, expliquei sobre as motivações envolvidas em aplicar o DDD em um projeto, e os cenários favoráveis pra isso.
Nesse artigo, quero resumir o que o Eric Evans incentiva como práticas de entendimento, destilação e implementação do domínio, usando um case pré-determinado como exemplo.
DDD é uma filosofia de desenvolvimento voltada para domínios de negócio complexos. Envolve um conjunto de práticas de entendimento do negócio, comunicação, colaboração, e desenvolvimento de uma solução emergente que reflita o domínio pelo próprio código.
Que práticas são essas? Como aplicá-las?
O início de um projeto de software surge a partir de uma necessidade de um indivíduo ou empresa. A prática recomendada pelo Eric Evans, o “fundador” do DDD, de entendimento dessa necessidade para se atingir a solução é o Design Dirigido a Modelos, ou Model Driven Design. …
Percebo que o DDD (Domain-Driven Design) é um assunto cada vez mais procurado por desenvolvedores. Mesmo assim, seu significado pode ser bem confuso para algumas pessoas.
Se você nunca ouviu falar, ou já ouviu mas quer ter outra perspectiva, ou ainda fica na dúvida a respeito dos pontos abaixo, esse artigo é pra você :)
Boa leitura!
O DDD é uma filosofia de desenvolvimento divulgada por Eric Evans desde 2003. “Divulgada” por que nem tudo foi criação dele. Ele percebeu que um conjunto de boas práticas de desenvolvimento, trabalho em equipe e estratégias de negócio podem contribuir para que um projeto complexo seja bem sucedido. …