O branch new-feature é inicializado em um novo repositório, para o qual o conteúdo do repositório original é copiado e ao qual é adicionada a nova versão do arquivo oldfile.c, bem como o arquivo newfile.c. 

O branch new-feature é selecionado e preparado para commit, o qual ocorre subsequentemente, criando uma nova versão, que contém o arquivo oldfile.c modificado, assim como o novo arquivo newfile.c.

O branch new-feature é criado no mesmo repositório e definido com espaço de trabalho, o qual contém a nova versão do arquivo oldfile.c, mas não o arquivo newfile.c.

O branch new-feature é criado no mesmo repositório e nele é criada uma nova versão, a qual contém o arquivo modificado oldfile.c, assim como o novo arquivo newfile.c. 

CI encorajar o uso de repositórios distintos para evitar interferência entre as diferentes tarefas de desenvolvimento em um projeto, com integração frequente dos repositórios e uso de testagem automática para garantir a ausência de erros, enquanto CD requer o empacotamento e deployment automáticos para reduzir o impacto de mudanças. 

CI envolver o uso de um repositório compartilhado, com automação de build e testagem a cada commit, enquanto CD envolve o empacotamento automático de cada build bem-sucedida, gerando uma nova release e deixando-a pronta para implantação (deployment) nos diferentes ambientes de produção.

CI requerer a realização contínua e automática de testes de integração para garantir que mudanças no código-fonte realizadas nos diferentes ramos (branches) do repositório não comprometam o comportamento correto dos componentes do sistema, enquanto CD envolve a implantação em ambiente de produção para a realização de testes em ambiente real.

CI determinar o emprego de testes unitários automáticos, eliminando a necessidade de testes manuais e garantindo que o comportamento do sistema permaneça correto após cada mudança, enquanto CD implica a realização automática de testes de integração após cada build e o subsequente empacotamento para deployment.

hardware (bare metal) de processamento e dispositivos de armazenamento instalados e administrados na infraestrutura de um provedor e que podem ser alocados aos clientes por meio de contratos de prestação de serviço.

sistemas de suporte ao desenvolvimento e operação de aplicações, os quais são hospedados na infraestrutura de um provedor e podem ser utilizados como serviço pelos clientes, sendo que o faturamento é realizado com base na quantidade de uso.

contêineres, máquinas virtuais e recursos de armazenamento, alocados elasticamente aos clientes por meio de APIs de serviço que permitem o faturamento com base no tipo de recurso e no tempo de alocação.

máquinas virtuais e capacidade de armazenamento, que podem ser escalados de forma elástica para atender a demanda dinâmica das aplicações, podendo sua alocação aos clientes ser gerenciada automaticamente por meio de APIs de serviços Web.

Apenas as camadas de Aplicação e Dados.

Apenas as camadas de Middleware e Sistema de Tempo de Execução. 

Apenas as camadas de Virtualização e Servidores. 

Apenas as camadas de Aplicação, Dados e Sistema de Tempo de Execução.

a tomada de decisão sobre a relação custo-efetividade da arquitetura quanto ao uso de recursos de nuvem deve ser realizada de forma centralizada para melhor explorar as oportunidades de otimização e permitir que as equipes de engenharia se concentrem nas soluções de aplicação.

a otimização de descontos oriundos do uso comprometido de recursos de nuvem deve ser gerenciada de forma centralizada para melhor aproveitar economias de escala e permitir que as equipes de engenharia mantenham o foco no uso otimizado dos recursos. 

os relatórios de gastos com serviços de nuvem sejam restritos à administração central, que pode definir e guiar os ajustes necessários, evitando sobrecarregar as equipes operacionais e de engenharia, as quais podem se concentrar nos aspectos de DevOps.

o orçamento de cada equipe de DevOps seja definido de forma centralizada, incluindo a atribuição de rubricas de recursos financeiros para gasto com tecnologias específicas, com o objetivo de otimizar globalmente o uso dos recursos na nuvem.

Controlar, dinamicamente, a quantidade de máquinas virtuais utilizadas para executar o número de réplicas de um microsserviço necessárias para atender a carga de trabalho gerada pelos clientes.

Aumentar ou reduzir a quantidade de recursos alocados para os pods que executam as instâncias de um determinado microsserviço, de modo a atender a demanda atual de carga de trabalho gerada pelas aplicações.

Realizar o ajuste automático da quantidade de réplicas de pods que executam um determinado microsserviço com base em métricas de uso e na carga de trabalho atual gerada pelos clientes do microsserviço.

Garantir a escalabilidade de um microsserviço por meio do ajuste dinâmico da quantidade de pods utilizados para executá-lo, com base no monitoramento de métricas de desempenho e do volume de carga de trabalho.

gerenciar os contêineres em um nó, garantindo que todos os contêineres descritos na especificação de pods do nó estejam ativos e funcionando corretamente. 

escalonar contêineres para executarem em pods específicos visando à otimização do uso de recursos e ao balanceamento de carga em um nó.

armazenar informações de estado do cluster para uso na recuperação dos nós após a ocorrência de falhas.

controlar o mapeamento de endereços IP e números de porta para tornar os contêineres acessíveis externamente.

No lado do cliente, o que é suficiente para verificar se as requisições estão corretas e evitar que requisições malformadas sejam enviadas para o servidor, melhorando a usabilidade e eliminando tráfego desnecessário.

No API Gateway, para verificar a conformidade com o esquema de requisições, evitando a necessidade de verificação de erros pelo servidor e padronizando a validação entre os vários microsserviços. 

No lado do cliente para verificar regras de formatação, melhorando a usabilidade e reduzindo tráfego desnecessário, assim como no lado servidor para garantir segurança e conformidade com a interface do serviço.

No lado do servidor, em se tratando de requisições a APIs publicamente acessíveis, ao passo que requisições internas entre os microsserviços da aplicação podem ser validadas apenas pelo microsserviço chamador.

Declarar PixTransfer como subclasse tanto de AbstractTransaction quanto de outra classe concreta responsável por logging, resolvendo eventuais conflitos de métodos por meio de sobrescrita explícita.

Declarar PixTransfer como subclasse de AbstractTransaction e fazendo-a implementar, simultaneamente, Auditable e Reversible, sobrescrevendo explicitamente eventuais métodos default conflitantes definidos nas interfaces.

Declarar Auditable e Reversible como classes abstratas em vez de interfaces, permitindo que PixTransfer herde múltiplas implementações e confiando na ordem de resolução de métodos da linguagem para tratar conflitos.

Declarar PixTransfer de forma que ela simplesmente implemente Auditable e Reversible, uma vez que a herança de interfaces permite reutilização implícita de estado e comportamento equivalente à herança de uma classe abstrata.

Permitir o uso de sistemas externos reais, como bancos de dados e serviços Web, em testes unitários, o que também permite reproduzir ambientes de execução realistas e melhorar a cobertura dos testes. 

Gerar dados de teste aleatorizados em cada execução, de modo a aumentar a variabilidade dos dados de entrada e, dessa forma, melhorar a confiabilidade, cobertura e robustez dos testes unitários.

Utilizar extensivamente a espera temporizada, como em Thread.sleep(), em testes concorrentes, de modo a estabilizar falhas relacionadas com temporização e reduzir a incidência de comportamentos intermitentes.

Lançar mão de implementações simuladas (mockups) em lugar do acesso ao relógio local e a serviços externos, isolando a unidade em teste e garantindo que cada teste seja independente de efeitos externos.