DevOps é uma cultura baseada em práticas, modelos e ferramentas integrativas, que permite a eliminação de diferenças entre desenvolvedores e operadores que atuam na área da engenharia de softwares, tendo por objetivo manter um ritmo de trabalho complementar e constante, que atenda à demanda frequente por atualizações em sistemas complexos das organizações atuais. As ferramentas são fundamentais para que a dinâmica DevOps tenha sucesso, pois são elas que otimizam os processos, elevam o nível de confiabilidade e a automação em todas as etapas dos projetos. Entre essas ferramentas, uma fornece maior segurança aos aplicativos, sendo utilizada para empacotar aplicações e ambientes em contêineres, tendo se popularizado por facilitar a portabilidade dos projetos de engenharia de software. Dessa forma, a aplicação pode ser, simplesmente, replicada em outras máquinas rapidamente, agilizando a construção de diferentes partes dos programas.
Essa ferramenta é conhecida como:

Na metodologia de softwares tradicionais, primeiramente o código é desenvolvido, sendo ajustado de maneira retroativa para fins de validação. Em contrapartida, o Desenvolvimento Orientado a Testes (TDD) emprega uma metodologia que modifica esse paradigma, preconizando que os testes sejam escritos antes e que as adaptações sejam, só depois, aplicadas ao código, até que o projeto atenda aos requisitos do teste já definido. Nesse contexto, a figura mostra o fluxo de trabalho do TDD, com destaque para as etapas e sua natureza ágil, cíclica e iterativa. 

Nesse esquema, a etapa I indica que o código não funciona, a II que tudo está funcionando, não necessariamente de maneira otimizada e, finalmente, a III em que o responsável otimiza o código, confiante de que o mesmo passou por vários testes, tendo sido alterado, aprimorado e chegado à versão final com mais segurança.
As etapas I, II e III são conhecidas, respectivamente, como:

O ciclo de vida de um software é uma estrutura que indica processos e atividades envolvidas no desenvolvimento, operação e manutenção de um software, abrangendo de fato toda a vida do sistema. Existem diversos modelos de ciclos de vida para o desenvolvimento de software, sendo um deles ilustrado por meio da figura.

Esse modelo de ciclo de vida é conhecido pela seguinte denominação:

Arquitetura de software é a estrutura fundamental ou o arcabouço de um sistema de software, que define seus componentes, suas relações e seus princípios de projeto e evolução, envolvendo um conjunto de normas, princípios e técnicas para construção de software. Entre os tipos de arquitetura de software, o padrão MVC é bastante flexível, com alta escalabilidade e reusabilidade. Como característica, faz a separação da apresentação e a interação dos dados do sistema, que é estruturado em três componentes lógicos. O primeiro, estabelece as regras de negócio, interage com o sistema de dados e faz as operações associadas aos dados. O segundo, define e gerencia como os dados são apresentados ao usuário. Para finalizar, o terceiro, corresponde à camada intermediária, interage com o usuário por meio de teclas, cliques do mouse e requisições.
Esses três componentes lógicos são denominados, respectivamente:

O gerenciamento de configuração é um processo de engenharia de sistemas para estabelecer a consistência dos atributos de um produto ao longo da vida, sendo que no mundo da tecnologia, constitui um processo de gerenciamento de TI que monitora itens de configuração individuais de um sistema de TI. Entre as ferramentas utilizadas nesse tipo de gerenciamento, uma constitui o sistema de controle de versão líder do setor para rastrear alterações de código. Nesse sentido, adicionar dados de gerenciamento de configuração ao lado de código em um repositório dessa ferramenta, possibilita uma visualização holística de controle de versão de um projeto inteiro.
Essa ferramenta de configuração é conhecida como:

Design Thinking é uma abordagem que se utiliza do pensamento do design como uma forma de encontrar as necessidades humanas e criar novas soluções usando as ferramentas e mentalidades de múltiplas disciplinas. Entre as técnicas de Design Thinking, uma fornece uma narrativa visual que promove empatia e comunica com o contexto, no qual uma tecnologia será usada. Tem por objetivo criar uma sequência de imagens, organizada quadro a quadro, para ajudar a capturar visualmente os fatores sociais, ambientais e técnicos importantes que moldam o contexto de como, onde e por que as pessoas se envolvem com os produtos.
Essa ferramenta é conhecida como:

A Orientação a Objetos (OO) constitui um paradigma aplicado na programação, que consiste na interação entre diversas unidades chamadas de objetos. A Programação Orientada a Objetos se apoia em quatro pilares principais, sendo que em um deles realiza-se o agrupamento das coisas que fazem sentido estarem juntas, para fins de organização e reutilização melhor do código. Em outro pilar, tem-se a possibilidade de um objeto assumir diversas formas diferentes na orientação a objetos.
Esses dois pilares da OO são conhecidos, respectivamente, como:

A arquitetura de software de microsserviço permite que um sistema seja dividido em vários serviços menores, individuais e independentes, que são executados como processos autônomos e se comunicam entre si por meio de APIs. Cada microsserviço pode ser implementado em uma linguagem de programação diferente em uma plataforma diferente. Entre os tipos de microsserviços, um combina vagamente os serviços com a funcionalidade relacionada, enquanto que outro facilita a interação entre aplicativos não relacionados. Esses tipos de microsserviços são denominados, respectivamente, de:

O Desenvolvimento orientado por comportamento (BDD) refere-se a uma técnica de desenvolvimento ágil, que visa integrar regras de negócios com linguagem de programação, focando o comportamento do software. Tem como objetivo melhorar a colaboração entre desenvolvedores, analistas de negócios e stakeholders, para que todos possam ter uma compreensão clara das expectativas em relação ao software. Para aplicar o processo de BDD de forma eficiente, é necessário seguir uma ordem específica, que inclui quatro etapas distintas, caracterizadas a seguir.
I.É a fase em que o Product Owner explica a visão geral do negócio, na qual a equipe utiliza o processo de discussão do BDD para reunir exemplos de usuários e entender como a função fornecida é usada, identificando problemas e possíveis novas regras de negócios.
II.É a fase em que a equipe faz perguntas para determinar quais regras, critérios de aceitação ou novas histórias podem ser criadas, na qual o esclarecimento das ideias ocorre por meio do diálogo entre os participantes.
III.É a fase em que todas as questões discutidas são agrupadas, criando um documento que contém todas as notas reunidas, na qual a linguagem Gherkin é geralmente recomendada ao criar critérios de aceitação.
IV.É a fase em que após pesquisar e testar a história, a equipe de desenvolvimento apresenta ao Product Owner para validação, na qual a história validada é utilizada durante a revisão da produção do projeto, para garantir que o produto corresponda aos padrões estabelecidos. Para finalizar, após a instalação do aplicativo no ambiente de produção, ocorre o monitoramento da funcionalidade para coletar feedback do cliente sobre o sistema desenvolvido.
As etapas descritas são conhecidas, respectivamente, como:

Representational State Transfer (Rest) representa um estilo arquitetônico aplicado para fornecer padrões entre sistemas de computador na web, facilitando a comunicação entre eles. No estilo REST, a implementação do cliente e do servidor pode ser feita de forma independente, sem que cada um conheça o outro, significando que o código do lado do cliente pode ser alterado a qualquer momento, sem afetar a operação do servidor, e o contrário também é válido. Os clientes que lidam com a arquitetura REST geram requerimentos para reaver ou alterar recursos, já os servidores assumem o papel de responder tais demandas. Uma solicitação, geralmente, consiste em HTTP - que define o tipo de operação a realizar, header - permitindo ao cliente transmitir informações sobre o pedido, um caminho para um recurso e o corpo de mensagem opcional contendo dados. Nesse contexto, quanto ao verbo HTTP, é fundamental conhecer quatro entradas básicas. A primeira para recuperar um recurso específico (por id) ou uma coleção de recursos, a segunda, para criar um novo recurso, a terceira para atualizar um recurso específico (por id) e a quarta e última para remover um recurso específico por id.
Essas entradas básicas são conhecidas, respectivamente, como: