Universidade de Aveiro Departamento de Eletrónica,Telecomunicações e Informática 2020
Gil Guilherme
Caçador Fernandes
Mesquita
Integração, entrega e implementação contínua em
ambiente cloud
Continuous integration, delivery and deployment in
cloud environment
Universidade de Aveiro Departamento de Eletrónica,Telecomunicações e Informática 2020
Gil Guilherme
Caçador Fernandes
Mesquita
Integração, entrega e implementação contínua em
ambiente cloud
Continuous integration, delivery and deployment in
cloud environment
Dissertação apresentada à Universidade de Aveiro para cumprimento dos re quisitos necessários à obtenção do grau de Mestre em Engenharia Informá tica, realizada sob a orientação científica do Doutor José Moreira, Professor auxiliar do Departamento de Eletrónica, Telecomunicações e Informática da Universidade de Aveiro e do Eng. Rafael Peixinho, engenheiro de qualidade de software na Bosch Aveiro.o júri / the jury presidente / president Prof. Doutor Helder Troca Zagalo professor auxiliar do Departamento de Eletrónica, Telecomunicações e Informática da Universi dade de Aveiro vogais / examiners committee Prof. Doutor Alexandre Valle Carvalho professor auxiliar da Faculdade de Engenharia da Universidade do Porto Prof. Doutor José Manuel Matos Moreira professor auxiliar do Departamento de Eletrónica, Telecomunicações e Informática da Universi dade de Aveiro
agradecimentos / acknowledgements
Gostaria inicialmente de agradecer aos meus orientadores, professor Dou tor José Moreira e Eng. Rafael Peixinho, por toda a disponibilidade e ajuda prestada no decorrer do meu estágio e durante a realização deste trabalho. Ao professor Doutor Ilídio Oliveira, obrigado pela prestabilidade com que me indicou alguma bibliografia e material de consulta, enriquecendo desta forma o trabalho. Um obrigado também aos meus colegas de estágio pela forma como me re ceberam, pelo conhecimento transmitido e especialmente pelo convívio, que proporcionou um ambiente de excelência. Não menos importante, gostaria de agradecer à minha família e a todas as pessoas são importantes na minha vida. Os meus sinceros agradecimentos por toda a confiança que depositaram em mim e por toda a ajuda que me disponibilizaram durante esta etapa do meu percurso académicoprofissional.
Palavras Chave integração contínua, entrega contínua, implementação contínua, internet das coisas, nuvem, computação em nuvem. Resumo Vivemos num tempo em que as inovações tecnológicas vão surgindo a um ritmo muito acelerado com avanços significativos na área do desenvolvimento de aplicações que procuram garantir a conectividade de dispositivos com a fi nalidade de melhor servir os utilizadores e de permitir um ambiente de desen volvimento contínuo das suas funcionalidades operacionais. É neste contexto que os principais players atuam e desejam garantir um posicionamento alta mente competitivo alcançando níveis de excelência nos seus processos de desenvolvimento, de forma a poderem garantir maior eficiência e, ao mesmo tempo, maior capacidade para superar as expectativas do mercado, sem des curar, naturalmente, as condições de segurança que poderão ser encaradas como fator crítico de sucesso. O desenvolvimento expectável ao nível da rede de comunicações e de plataformas de comunicação baseadas em soluções cloud criam o ambiente favorável a todo este processo. Este estudo teve como base de trabalho o ambiente interno da BOSCH Aveiro e através dele procurase avaliar as condições existentes no que respeita à preparação do capital humano e à adequação das ferramentas usadas para o suporte ao desenvolvimento aplicacional, associandose a este propósito a análise de soluções cloud. Neste estudo apresentamos as conclusões dessa análise e concluímos com um conjunto de considerações e de recomendações que apontam para a definição de uma estratégia de implementação de uma so lução de CI/CD que satisfaça a capacidade visionária demonstrada por este tipo de organização.
Keywords continuous integration, continuous delivery, continuous deployment, internet of things, cloud, cloud computing.
Abstract We live in a time where technological innovations are emerging at a very rapid pace with significant advances in application development that seek to ensure device connectivity, in order to better serve users and enable a continuous feature development environment. It is in this context that the main players act and want to ensure a highly competitive positioning, achieving levels of excellence in their development processes, so that they can ensure greater efficiency and, at the same time, greater ability to exceed market expecta tions, without neglecting, of course, the safety conditions that could be viewed as a critical success factor. The expected development of the communica tions network and communication platforms based on cloud solutions creates a favorable environment for this whole process. This study was based on the internal environment of BOSCH Aveiro and seeks to evaluate the conditions re garding the preparation of human capital and the adequacy of the tools used for software development support. A set of cloud solutions were analyzed, being the conclusions presented in this paper, along with a set of considera tions and recommendations that point to the definition of a strategy for CI/CD implementation solution that satisfies the visionary capacity demonstrated by this type of organization.
Conteúdo
Conteúdo i
Lista de Figuras v
Lista de Tabelas vii
Glossário ix 1 Introdução 1 1.1 Contexto e motivações . . . 1 1.2 Desafios . . . 2 1.3 Objetivos . . . 3 1.4 Estrutura do documento . . . 3 2 Estado da arte 5 2.1 Globalização do mercado Internet of things (IoT) . . . 5
2.2 Oportunidades . . . 6 2.2.1 Saúde . . . 7 2.2.2 Segurança . . . 8 2.2.3 Comodidade e eficiência . . . 9 2.2.4 Segmentação de indivíduos . . . 10 2.3 Desafios . . . 11 2.3.1 Infraestrutura de desenvolvimento . . . 11 2.3.2 Infraestrutura de comunicação . . . 12 2.3.3 Segurança . . . 12 3 Levantamento de requisitos 15 3.1 Visualização do ambiente tecnológico em uso na divisão da Termotecnologia (TT) . . 15
3.1.1 Requisitos e casos de uso . . . 15
3.2 Estudo da maturidade das equipas da TT a respeito de Continuous integration, delivery and deployment (CI/CD) . . . 16
3.2.1 Requisitos e casos de uso . . . 16
3.3 Avaliação de ferramentas cloud para efeitos de CI/CD . . . . 17
3.3.1 Requisitos e casos de uso . . . 17
4 Análise do ambiente tecnológico - Technology Radar 19 4.1 Introdução . . . 19
4.2 Arquitetura e implementação . . . 20
4.2.1 Integração com o Docker . . . . 20
4.2.2 Integração com o Jenkins . . . . 21
4.3 Atualização do Technology radar . . . 23
4.3.1 Separação das tecnologias . . . 23
4.3.2 Visualização complementar das ferramentas . . . 24
4.4 Discussão e resultados . . . 25 5 Modelo de maturidade 27 5.1 Introdução . . . 27 5.1.1 Integração contínua - CI . . . 27 5.1.2 Entrega contínua - CD . . . 28 5.1.3 Implementação contínua - CD . . . 28 5.1.4 Relevância do CI/CD . . . 28
5.2 Como medir o nível de CI/CD . . . 29
5.3 Discussão e resultados . . . 31
5.3.1 Equipas Non embedded . . . 31
5.3.2 Equipas embedded . . . 32
5.3.3 Sumário . . . 33
6 Soluções cloud 35 6.1 Problemas e motivações . . . 35
6.2 Bosch Development cloud . . . 36
6.2.1 Cenário atual . . . 37
6.2.2 Serviços atuais VS serviços na cloud . . . 38
6.2.3 Requisitos de integração entre ferramentas . . . 38
6.2.4 Prova de conceito - PoC . . . 39
6.3 Azure DevOps . . . 41
6.3.1 Azure DevOps VS Bosch Development Cloud (BDC) . . . 42
6.3.2 Prova de conceito - PoC . . . 42
6.4 Limitações e trabalho futuro . . . 44
6.5 Discussão e resultados . . . 45
6.5.2 Azure DevOps . . . 46 6.5.3 Sumário . . . 46 7 Conclusões 47 Referências 49 Appendix A . . . 52 Appendix B . . . 54 Appendix C . . . 56 Appendix D . . . 64
Lista de Figuras
2.1 Crescimento do mercado IoT[1] . . . 6
2.2 IoT na área da saúde [3] . . . 8
2.3 Ciclo ideal da arquitetura smart city [13] . . . 10
2.4 DevSecOps . . . 13
3.1 Casos de uso TT Technology Radar . . . 16
4.1 Exemplo Technology radar . . . 20
4.2 Arquitetura TT Technology Radar . . . 21
4.3 Resultado TT Technology radar . . . 22
4.4 Resultado TT Technology radar - teams feature . . . 23
4.5 Technology radar update . . . 24
4.6 Vista geral sobre as ferramentas . . . 25
4.7 Ferramentas da categoria Code Analysis Testing . . . . 25
5.1 CI/CD . . . 27
5.2 CI/CD - ciclo de vida . . . 28
5.3 CI/CD - Vantagens . . . 29
5.4 Questionário Maturity model continuous deployment (MMCD) . . . 30
5.5 Resultado MMCD . . . 30
5.6 Resultado MMCD - Média das equipas Non Embedded . . . 32
5.7 Resultado MMCD - Média das equipas Embedded . . . 33
6.1 IoT . . . 36
6.2 Ferramentas utilizadas atualmente . . . 36
6.3 Arquitetura do BDC . . . 37
6.4 Integração entre ferramentas . . . 38
6.5 Requisitos e disponibilidade no BDC . . . 39
6.6 Arquitetura do ambiente CI/CD no BDC . . . 40
6.8 Azure dashboard & Graphical user interface (GUI) . . . . 43
6.9 Requisitos e disponibilidade no Azure DevOps . . . 44
6.10 Outras soluções para CI/CD na cloud . . . 45
1 BDC VS serviços atuais . . . 53
Glossário
CI/CD Continuous integration, delivery and
deployment
TT Termotecnologia UX User experience TTM Time to market
MMCD Maturity model continuous deployment IoT Internet of things
SW Software
IT Information technology BCN Bosch connect network BDC Bosch Development Cloud
PoC Proof of concept SoCo Social coding
DevOps Development and operations AWS Amazon web services DTR Docker trust registry BIOS Bosch Internal Open Source GUI Graphical user interface IT Information technologies IDC International Data Corporation DevSecOps Development Security Operations
CAPÍTULO
1
Introdução
Nos dias de hoje, as constantes mudanças e inovações na área tecnológica, aliadas ao forte crescimento do setor do desenvolvimento de software e à competitividade daí resultante, são fatores desafiantes que levam as empresas a procurarem cada vez mais por soluções e metodologias que possibilitem uma maior agilização nos processos de desenvolvimento e manutenção dos produtos de software, de forma a conseguirem, rapidamente, disponibilizar produtos diferenciados que satisfaçam as exigências do mercado e permitam aumentar a rentabilidade, muitas vezes na base de novos modelos de negócio. As soluções cloud tem ganho uma grande popularidade nos últimos anos. Estas tecnologias apresentam potencial para dar resposta aos desafios mencionados anteriormente, especialmente no que diz respeito à área do IoT, sendo por isso objeto de estudo deste trabalho.
1.1 Contexto e motivações
Este trabalho é o resultado do estágio de mestrado feito em parceria com a Bosch Termo-tecnologia, situada em Aveiro. A divisão de termotecnologia da Bosch fornece produtos de aquecimento e soluções de água quente, com eficiência energética, principalmente na Europa. Os produtos da divisão são vendidos sob marcas internacionais e regionais, como Bosch, Buderus, Worcester, Vulcano e Junkers. O portfólio de produtos inclui desde aquecedores, bombas de calor, sistemas solares térmicos e caldeiras de combustível sólido, até plantas de cogeração e caldeiras industriais.
Tendo em vista funcionalidades como a monitorização e diagnóstico remotos, os dispositivos preparados para se ligarem à internet tornam-se cada vez mais usuais e por isso exigem uma abordagem dinâmica e, ao mesmo tempo, segura. É aqui que são desenvolvidas soluções tecnológicas na área da termotecnologia focadas na eficiência energética, casas inteligentes e conectividade - IoT.
Dadas as dificuldades identificadas na área de desenvolvimento de soluções de conectividade, o propósito e foco deste projeto passa pela otimização do processo de desenvolvimento de
software, em especial na análise de soluções cloud, como resposta aos desafios reais com que a empresa se depara atualmente no que diz respeito ao desenvolvimento IoT onde a mesma pretende ter um papel ativo.
1.2 Desafios
A necessidade de garantir a integração de funcionalidades e cooperação entre as equipas, tendo em conta a existência de múltiplos sistemas associados, exige que seja definida, tanto quanto possível, a normalização de procedimentos e de ferramentas tecnológicas em uso pelos diferentes serviços de desenvolvimento de aplicações.
Por outro lado, é necessário que os produtos de software daí resultantes possam servir os interesses dos clientes, os quais devem, rapidamente, poder ter acesso a essas atualizações que lhes devem proporcionar melhores experiências.
No primeiro caso, caberá à empresa assegurar as condições internas de funcionamento. É nesse sentido que desenvolvemos um capítulo dedicado à análise das tecnologias em uso na empresa.
No segundo caso, garantidas as condições de integração, o foco passará por garantir que esse processo possa ser desenvolvido de forma contínua, através do recurso a metodologias que garantam a conectividade ideal, de modo a que a entrega possa ocorrer de forma rápida, sem descurar, contudo, uma das maiores preocupações que a todos deve afligir: a qualidade e segurança das soluções propostas.
Deste modo, a integração e entrega de soluções, de forma contínua e com os níveis de qualidade desejados, poderão contribuir para incrementar o nível de satisfação alcançado pelos clientes, relativamente ao serviço prestado pela empresa e, também, a sua fidelidade à marca.
Para a empresa resultará no reforço do seu prestígio e da sua competitividade, face aos concorrentes, e em ganhos de produtividade e de eficiência económica.
Resumidos os principais desafios encontrados, os seguintes temas serão analisados: • Unificação de tecnologias
– A utilização de uma vasta diversidade de ferramentas para o mesmo efeito não é uma boa prática quando o objetivo é a cooperação entre as equipas de desenvolvimento. • Maturidade de CI/CD
– Os conceitos de continuous integration, delivery e deployment são aspetos funda-mentais e devem estar bem intrínsecos no seio das equipas, dada a sua relevância na agilização do processo de desenvolvimento de software.
• Desenvolvimento IoT
– Este novo mercado onde a empresa pretende vingar, acarreta novos paradigmas de desenvolvimento e desafios a si inerentes. Por esse motivo é necessário repensar a estrutura de desenvolvimento utilizada atualmente, tarefa que carece de novas áreas de conhecimento a ter em conta na deliberação.
1.3 Objetivos
Considerando os desafios anteriormente identificados, o objetivo deste projeto consiste em melhorar a agilização no processo de desenvolvimento de software, tendo em conta os constran-gimentos impostos pelo desenvolvimento IoT e as exigências crescentes no que diz respeito ao desenvolvimento de software. Para o efeito, por considerar que as melhores soluções resultam da partilha e do envolvimento das equipas de colaboradores, optou-se por uma estratégia de sensibilização para os temas seguintes:
• Sensibilização das equipas para a uniformização de ferramentas, tornando este tipo de informação transparente para todos os colaboradores - Capítlo 4 .
• Estudo da maturidade de CI/CD das equipas de desenvolvimento e sensibilização das mesmas quanto à relevância deste tema - Capítlo 5.
Para além da estratégia de sensibilização e partilha de informação descrita anteriormente, o objetivo final deste projeto passa por avaliar a viabilidade das soluções cloud disponíveis como resposta ao aos desafios impostos pelo IoT - Capítulo 6 .
1.4 Estrutura do documento
Este documento consiste em 7 capítulos, organizados da seguinte forma:
• Capítulo 2, Estado da arte: Neste capítulo pode ser encontrada uma introdução ao tema do IoT, apontando para o seu crescimento e globalização. São também evidenci-adas as oportunidades e desafios resultantes deste novo conceito. Dentro dos desafios identificados, é também mencionado aquele que será objeto de estudo nos capítulos de desenvolvimento, apontando para a sua relevância no que diz respeito à viabilidade do conceito IoT.
• Capítulo 3, Levantamento de Requisitos: Neste capítulo, são descritos os requisitos estabelecidos à priori para cada fase do trabalho proposto no âmbito do estágio. Es-tes consistiram no ponto de partida para o desenvolvimento do trabalho efetuado, descrevendo de forma clara os principais objetivos a alcançar.
• Capítulo 4, Análise do ambiente tecnológico - Technology Radar: Neste capítulo é mencionado todo o trabalho efetuado relativamente à análise do ambiente tecnológico encontrado, descrito o processo de criação da plataforma criada para a sumarização e partilha dessa informação, bem como mencionada a relevância destas tarefas.
• Capítulo 5, Modelo de maturidade: O quinto capítulo relata o trabalho feito com as equipas de desenvolvimento na tentativa de identificar e tornar percetivel a maturidade das mesmas no que diz respeito a CI/CD. É dada ênfase à importância destes temas para uma maior e melhor produtividade e feita uma discussão dos resultados obtidos, identificando os pontos a melhorar.
• Capítulo 6, Soluções cloud: No capítulo sexto é feito um comparativo entre as ferramentas de desenvolvimento atuais e algumas soluçoes na cloud, sendo descrito todo o trabalho desenvolvido no sentido de testar as soluções cloud Azure DevOps e BoschDevCloud.
Por fim é também feita uma discussão e análise onde, com base nos resultados obtido, são tiradas conclusões acerca da viabilidade destas soluções para a empresa.
• Capítulo 7, Conclusões: O último capítulo sumariza as secções de discussão de resultados presentes nos capítulos de desenvolvimento 4, 5 e 6 e faz a ligação entre o estado da arte tratado no capítulo 2 e o trabalho efetuado, evidenciando o contributo dado com este projeto.
CAPÍTULO
2
Estado da arte
Com a proliferação do conceito de IoT e a transformação digital vivida atualmente, é expectável que, num futuro muito próximo, grande parte das empresas dos mais distintos setores, passem a integrar o desenvolvimento de software nos seus modelos de negócio. Dado este facto, é de antever novas oportunidades de negócio, acompanhadas de uma competitividade crescente, onde os processos e infraestruturas adequadas ao desenvolvimento de software terão grande impacto no sucesso das empresas, permitindo por um lado a agilização no desenvolvimento, criação de novos serviços de valor para os clientes, bem como a manutenção dos padrões de qualidade desejados.
2.1 Globalização do mercado IoT
Inicialmente a Internet surgiu como forma de ligar as pessoas e tornar a informação acessível a todos, no entanto, nos dias de hoje este conceito evoluiu para algo maior - O conceito de IoT já aprofundado no capítulo 1. Sobre este domínio, segundo um estudo efetuado pela International Data Corporation (IDC) em 2016 [1], até ao final do ano de 2020 os dispositivos IoT vão chegar perto dos trinta mil milhões de dispositivos em todo o mundo (Figura 2.1) e o valor de mercado nesta área irá crescer cerca de 7.1 triliões de dólares [2] . As previsões apontam para que o número de dispositivos tenda a crescer proporcionalmente ao número de objetos físicos que conhecemos do dia a dia, onde os mesmos podem ir desde dispositivos domésticos, como microondas ou frigoríficos a dispositivos como semáforos ou carros, todos interligados e com informação partilhada a todo o momento, a partir de qualquer parte.
Figura 2.1: Crescimento do mercado IoT[1]
Numa época onde os dados são um bem valioso, ultrapassando até o valor do petróleo, a quantidade de dados gerada por estes dispositivos e a possibilidade dos mesmos serem analisa-dos e partilhaanalisa-dos, em tempo real, num ambiente heterogéneo de dispositivos, despoleta novas e promissoras oportunidades de negócio. Não menos importantes, estas novas oportunidades acarretam também, desafios ao nível da infraestrutura de suporte ao IoT e à segurança e privacidade dos dados em trânsito. Pela importância destes tópicos, os mesmos são objeto de estudo nas secções seguintes.
2.2 Oportunidades
A ideia de um mundo onde todo o tipo de dispositivos estão interligados e partilham abundantes quantidades de informação através da rede, despoleta várias oportunidades de inovação e novos modelos de negócio que estão já a ser exploradas pelas grandes tecnológicas mundiais, muito embora de forma ainda pouco exaustiva. Neste domínio, podem ser observadas várias áreas onde o potencial do IoT pode ser explorado, de forma a melhor a vida das pessoas:
• Saúde
– Dispositivos de uso pessoal que fazem a monitorização regular de sinais vitais, identificando e prevenindo possíveis problemas de saúde.
• Segurança
– Dispositivos de vigilância que fazem a monitorização e identificação de possíveis ameaças, com aplicação em carros, casas ou espaços públicos.
– O conceito de smart home, onde dispositivos de uso doméstico como frigorífi-cos, estores, ar condicionado, entre outros, tem um comportamento autónomo e inteligente, podendo ser controlados de forma remota.
– O conceito de smart city, onde dispositivos citadinos como semáforos, iluminação publica, sistemas de rega tem um comportamento autónomo e inteligente, tornando o seu funcionamento mais eficiente.
• Segmentação de indivíduos
– Com a grande quantidade de dados produzida por todos os dispositivos, será possível identificar padrões, quer ao nível do consumo quer ao nível comportamental. Esta informação poderá posteriormente ser utilizada para segmentar grupos de indivíduos para os mais variados fins.
2.2.1 Saúde
O setor da medicina e saúde é atualmente uma das áreas mais atrativas para a aplicação do IoT [3], [4]. Monitorização remota do estado de saúde dos pacientes, aplicações ao nível de programas de treino físico, controlo de doenças crónicas ou o cuidado de pessoas idosas, são alguns dos inúmeros exemplos de casos de uso onde a tecnologia IoT pode dar o seu contributo de forma a gerar valor acrescentado ao que já é possível fazer atualmente.
Através das várias partes integrantes num sistema IoT, como sensores (respiratórios, cardíacos, etc), aplicações móveis, e a integração de toda a informação com sistemas de análise em tempo real onde a informação é acessível em qualquer parte do mundo, será então possível reduzir custos, melhorar a qualidade de vida e proporcionar uma agradável experiência de utilização aos utilizadores [3].
Na Figura 2.2 pode ser observada a arquitetura atualmente explorada neste contexto. A facilidade e o baixo custo de comunicação entre pacientes e médicos ou organizações de saúde, bem como a garantia da segurança das vias de comunicação, são sugeridas em vários estudos [3], [5] como aspetos chave para o sucesso desta área de aplicação do IoT, sendo por isso os principais desafios enfrentados atualmente.
Figura 2.2: IoT na área da saúde [3] 2.2.2 Segurança
Na área da segurança, são já frequentes sistemas de vídeo vigilância e deteção de ameaças com recurso a câmaras ligadas em rede e sistemas inteligentes que processam e analisam os dados em tempo real de forma a monitorizar e prevenir ameaças. Este tipo de sistema pode ser aplicado em vários ambientes: casas; carros; espaços públicos; podendo , dentro de cada ambiente, ser utilizado para finalidades distintas como descrito seguidamente.
Em casas ou carros, já são correntemente explorados sistemas de video porteiro ou sensores de som e imagem inteligentes baseados na tecnologia IoT, de forma a garantir a segurança e integridade destes bens [6] [7]. Dentro do mercado automóvel, existem já projetos pioneiros e até marcas de renome com evoluções nesta área, como é o caso da Tesla, onde os seus mais recentes modelos automóveis incluem um sistema de deteção e vigilância continua de possíveis ameaças, alertando atempadamente os seus proprietários e dando-lhes oportunidade de tomar medidas de alerta em tempo real para dissuadir possíveis mal feitores. Dentro do ambiente das casas, é também evidente a aplicação destes sistemas ao nível da vigilância de crianças, garantindo a sua segurança e bem estar através dos mais variados tipos de sensores, colocados por exemplo em brinquedos.
Nos casos de aplicação em espaços públicos, podem ser já encontrados estudos neste sentido [8], onde os mesmos podem ser aplicados em diversos locais de acesso público, como por exemplo: bancos, aeroportos, parques de estacionamento, entre outros. Com esta possibilidade é expectável que se consiga garantir de forma mais eficiente a segurança destes locais.
De entre todos os estudos que foram analisados e que foram sendo mencionados ao longo desta secção, foi possível concluir que o foco e principal desafio destes sistemas tem sido a eficácia e eficiência dos seus algoritmos de deteção de ameaças [6] e mais uma vez, tal como na área da saúde, a segurança e integridade dos dados coletados, prevenindo que estes sejam
passiveis de acesso por parte de terceiros [9]. Dada a sensibilidade dos dados e sistemas em questão, caso os dados possuam falhas de segurança que permitam o acesso de terceiros, os riscos podem ser elevados. Por este motivo esta deve manter-se como a principal prioridade em desenvolvimentos futuros.
2.2.3 Comodidade e eficiência
Smart home e Smart city são conceitos já bastante bastante falados nos dias de hoje, sendo
também conhecida a sua ligação à tecnologia IoT. Estes conceitos inserem-se dentro do contexto da comodidade e eficiência uma vez que o seu principal objetivo é servir os interesses dos seus utilizadores pela automação e eficiência que proporcionam.
Smart home
No caso das smart homes, falamos de dispositivos de uso doméstico ligados em rede, acessíveis de qualquer parte do mundo. Este tipo de aplicações tem proliferado nos últimos anos, com casas cada vez mais inteligentes, onde grande parte das tarefas podem ser já automatizadas e controladas remotamente, por via de dispositivos dotados de conectividade como estores, aspiradores, TV’s, iluminação, electrodomésticos, entre outros.
Neste contexto é de salientar dispositivos como google home ou amazon alexa, que tem evoluído no sentido de servir de intermediário entre a heterogeneidade de dispositivos que se podem encontrar no domínio de smart homes[10]. Estes dispositivos permitem o controlo de todos os dispositivos no universo das smart homes com um acesso uniformizado através de comandos de voz, que de outra forma seriam individualmente controlados através da infraestrutura providenciada pelo fabricante de cada dispositivo para o efeito. Tal peculiaridade é interessante, especialmente para pessoas com limitações físicas, onde as mesmas deixam de estar dependentes da mobilidade para realizarem as tarefas como colocar a roupa a lavar, acender o fogão ou ligar o ar condicionado.
Para além de todas as comodidades providenciadas por estes dispositivos, vale a pena frisar a eficiência energética que tais mecanismos proporcionam [11]. É evidente se se pensar em tarefas como: a iluminação da casa, regulação da temperatura ou gestão dos electrodomésticos, a eficiência energética que pode ser atingida por meio da automatização e gestão inteligente destes recursos. Esta gestão inteligente dos recursos torna-se ainda mais relevante e pertinente nos dias de hoje, onde cada vez mais sentimos os efeitos negativos que décadas de má gestão produziram, como são exemplos o aquecimento global e efeito de estufa.
smart city
O conceito de smart city surgiu no início da década de noventa, com o intuito de conceptualizar o desenvolvimento urbano dependente da tecnologia e inovação. A ideia inicial era tornar as cidades mais tecnológicas, aproveitando os avanços tecnológicos para providenciar aos cidadãos serviços que tornassem as suas vidas mais cómodas [12]. Contudo, durante a última década, os avanços tecnológicos foram tão expressivos, e a vida das pessoas tornou-se tão dependente das tecnologias, que este conceito de cidades inteligentes se alterou, evoluindo para um cenário onde não apenas serviços simples são disponibilizados aos cidadãos, mas
também as tecnologias da informação ajudam na gestão eficiente dos recursos disponíveis [13], contribuindo desta forma para um objetivo coletivo que tão importante é nos dia de hoje em que tanto se discute sobre os efeitos negativos causados pela ineficiente gestão destes mesmos recursos.
Assim sendo, em termos práticos e seguindo a abordagem de estudos prévios, podemos descrever de forma genérica a arquitetura de uma smart city da seguinte forma: Em pri-meiro lugar a enorme quantidade de dados gerada pelos dispositivos citadinos conectados à Internet (semáforos, meios de transporte, sensores, redes de comunicação, etc); seguidamente uma infraestrutura capaz de analisar e criar informação relevante com base na quantidade massiva de dados heterogéneos produzidos; a industria, cidadãos, governos ou genericamente
stakeholdersque tomam decisões mais acertadas com base nas informações providenciadas
pelas infraestruturas de análise; por último, a cidade e os seus cidadãos, que tiram proveito das decisões tomadas. Este ciclo, descrito na Figura 2.3, terá sempre como objetivo final a gestão eficiente dos recursos citadinos, quer seja a nível de gestão do tráfego, gestão dos tempos de espera dos semáforos, iluminação artificial, entre as mais diversas aplicações.
Figura 2.3: Ciclo ideal da arquitetura smart city [13] 2.2.4 Segmentação de indivíduos
Nos últimos anos temos assistido ao impacto que o acesso a massivas quantidades de dados sobre grandes quantidades de pessoas podem ter em cada um e na sociedade. São exemplos disso as propagandas direcionadas que recebemos diariamente nas redes sociais, e meios de comunicação digitais, as quais parecem não inocentemente, coincidir com os nossos gostos e ideologias pessoais. Este direccionamento de mensagens personalizadas para cada individuo ou grupos de indivíduos é resultado de análises efectuadas a grandes quantidades de dados obtidos através dos nossos comportamentos nas redes sociais e mesmo em grande parte da atividade na Internet em geral.
relevante para cada um, também se pode observar, por outro lado, a possibilidade de utilização deste mecanismo para fins eticamente questionáveis. Casos como eleições politicas e referendos a nível mundial tem sido polémicos por suspeitas de que os seus resultados tenham sido influenciados pela segmentação e direcionamento de mensagens para grupos de indivíduos através da análise de dados em massa. O mecanismo de segmentação nestes casos foi utilizado para manipular as pessoas e as suas escolhas através da disseminação de mensagens personalizadas, com conteúdo por vezes pouco factual. Pela relevância dos efeitos que estes acontecimentos têm trazido às sociedades a nível mundial, muito se tem discutido sobre a legitimidade do acesso aos dados, bem como da utilização destes mecanismos.
Estando o conceito de IoT intimamente ligado a grandes quantidades de dados sobre intervenientes tão heterogéneos, é de esperar que os mesmos, à semelhança do que acontece com os dados pessoais recolhidos através das redes sociais e Internet em geral, uma vez sujeitos aos mesmos mecanismos de análise, possibilitem a extração de informações que contribuam para a segmentação ainda mais refinada de indivíduos ou entidades mais abstratas. Tal como foi referido anteriormente, esta ferramenta tanto pode ser utilizada para fins mais ou menos corretos e, por este motivo, questões de segurança, legitimidade e proteção de dados, devem continuar a ser temas de debate, de forma a mitigar os riscos que advém do acesso e manipulação indevida a este tipo de informação.
2.3 Desafios
Se por um lado o crescimento do mercado IoT possibilita todas as oportunidades destacadas na secção anterior, por outro, também acarreta novos desafios e ameaças à viabilidade e longevidade das mesmas. Existem três áreas principais que desafiam e comprometem atualmente os progressos na área do IoT: Infraestrutura de desenvolvimento, infraestrutura de comunicação e segurança. O foco deste documento no o capítulo 6 será na experimentação de soluções que providenciem a infraestrutura de desenvolvimento adequada ao mercado IoT, contudo, nesta secção serão também aprofundadas as restantes áreas mencionadas.
2.3.1 Infraestrutura de desenvolvimento
Quando se fala em desenvolvimento de software, uma adequada infraestrutura de desenvolvi-mento é um dos pontos chave para o sucesso dos produtos desenvolvidos. Pela sua relevância no alcance do Time to market (TTM), qualidade e facilidade de manutenção dos produtos que permitem às empresas maximizar os seus lucros, os termos DevOps, CI/CD, e metodologias ágeis são conceitos que não são novidade para a maioria das empresas de software nos dias de hoje. As infraestruturas atuais, compostas por uma cadeia bem conhecidas de ferramen-tas como: Jenkins, Bitbucket, Docker, Sonarqube, Checkmarx, entre outras, viabilizam de forma eficiente, no contexto de desenvolvimento corrente, a implementação destas práticas da engenharia de software.
Não obstante do que foi dito anteriormente, as infraestruturas de desenvolvimento atual-mente utilizadas, tem-se revelado ineficientes no que toca ao novo paradigma do desenvol-vimento para dispositivos IoT. Desta forma têm sido notória a carência de infraestruturas
que permitam a comunicação eficiente com os dispositivos conectados à rede, viabilizando desta forma o bom funcionamento das funcionalidades previstas [14]. Vários produtos e serviços cloud como: Google cloud, Amazon web services (AWS), Microsoft Azure, tem sido desenvolvidos por nomes bem conhecidos da industria tecnológica, com o intuito de colmatar as falhas verificadas [15], no entanto, a sua efectividade ainda é pouco conhecida. Por esse motivo, é de realçar que este tema será o foco do capítulo 6 deste documento, onde se espera que o mesmo traga contributos significativos para o aprofundamento desta área.
2.3.2 Infraestrutura de comunicação
O crescimento dos dispositivos conectados à rede previsto à luz do conceito IoT e a necessidade de análise massiva dos dados recolhidos por esses dispositivos a cada instante, serão fatores que num futuro próximo tornarão as redes de comunicação atuais ineficientes. A rede 4G, atualmente em uso, será incapaz de dar resposta a estes desafios dadas as limtações no que diz respeito à taxa de transferência de dados, latência e largura de banda. Nesse sentido, a tecnologia 5G que tem vindo a ser desenvolvida nos últimos anos e que se prevê ser implementada já no próximo ano (2020), proporcionará um incremento significativo nos aspetos chave acima mencionados, permitindo alcançar velocidades de 1 Gigabyte por segundo já em 2020 e dez vezes mais a cada cinco anos seguintes, prevê-se [16]. Assim sendo, esta tecnologia emergente será determinante na viabilidade da visão do IoT [16], [17] tal como a conhecemos, onde todos os dispositivos estão conectados e partilham informação de forma a acrescentar valor através das diversas oportunidades já abordadas na secção anterior. 2.3.3 Segurança
O tema da segurança é um ponto crítico e talvez o que leva a maior descrença no que diz respeito às tecnologias IoT. Tal como foi brevemente abordado na secção das oportunidades (2.2), em cada uma das áreas de aplicação referidas, existem riscos relacionados com a importância dos dados que cada área trata. Assim sendo, o facto de estarmos cientes do poder e dos efeitos negativos que tamanha quantidade de dados pode ter quando utilizada de formas indevidas, torna apreensiva a idealização de um mundo onde os dados de quase tudo o que é tangível navegam livremente pela rede. Nesse sentido, esforços tem sido conduzidos com o intuito de tornar o ecossistema IoT o mais seguro possível, quer ao nível da arquitetura, quer ao nível do desenvolvimento direcionado para os dispositivos em si.
No que diz respeito ao modelo da arquitetura IoT, a tendência, tal como revelam vários estudos, é para a criação de centrais de controlo, onde os dispositivos conectados estarão constantemente sob monitorização. As mesmas centrais permitirão identificar vulnerabilidades e possíveis ataques em tempo real a qualquer dispositivo na rede [18]–[20], contribuindo desta forma para mitigar os efeitos de possíveis ataques e prevenir que estes aconteçam de futuro. Contudo, esta abordagem estará também dependente de fatores como a infraestrutura de comunicação utilizada, de forma a suportar a quantidade de tráfego inerente 2.3.2.
Relativamente à segurança no desenvolvimento de software e aplicações para os dispositivos IoT, é de realçar o recente surgimento de um novo conceito: Development Security Operations
último, consiste num conjunto de práticas que visam obter maior automação, mantendo ou melhorando a qualidade do processo de desenvolvimento, neste caso acrescentando valor ao nível da segurança dos produtos desenvolvidos. Na sua essência, este novo conceito é uma tentativa de unificar não apenas as pessoas responsáveis pelo desenvolvimento e operações (DevOps), mas também os profissionais da segurança, garantindo que as melhores práticas a este nível são implementadas o mais cedo possível durante o processo de desenvolvimento [21], [22]. O que se espera com esta nova tendência que já é seguida por empresas bem conhecidas [23], é que efetivamente permita às mesmas desenvolver produtos cada vez mais seguros, não comprometendo o desenvolvimento contínuo de novas funcionalidades e entregas contínuas de software necessárias para manter a competitividade crescente do mercado.
CAPÍTULO
3
Levantamento de requisitos
O objetivo principal deste projeto centrou-se na necessidade de agilizar o processo de desenvol-vimento de software, com recurso a tecnologias avançadas adaptadas às exigências do mercado, mantendo e, se possível, melhorando a qualidade dos produtos desenvolvidos. Considerado este desafio, dividiu-se o trabalho em três tarefas principais: criar uma visualização do
am-biente tecnológico em uso na divisão da Bosch TT - Technology radar; estudar a maturidade das equipas da TT relativamente a CI/CD; avaliar ferramentas cloud para efeitos de CI/CD. Assim sendo, para cada tarefa foram estabelecidos sub
requisitos que definem de forma clara os resultados esperados, guiando desta forma o desen-volvimento da solução para o problema. Nas próximas secções serão descritas as três tarefas propostas, os requisitos e, no caso do tecnology radar, os casos de uso correspondentes.
3.1 Visualização do ambiente tecnológico em uso na divisão da TT
Verificada a vasta diversidade de tecnologias usadas entre as equipas de desenvolvimento para os mais diversos fins, o propósito desta tarefa prende-se com a necessidade de tornar esta informação mais percetível através de um serviço web acessível a todos os colaboradores - TT
Technology radar. Esta abordagem visa trazer duas mais valias: possibilitar que, tanto quanto
possível, as tecnologias sejam uniformizadas entre as equipas; saber facilmente quem está a utilizar cada tecnologia, possibilitando a entreajuda entre os desenvolvedores.
3.1.1 Requisitos e casos de uso • Requisitos:
– O utilizador deve ser capaz de visualizar as tecnologias utilizadas por todas as equipas de desenvolvimento;
– As tecnologias devem estar categorizadas de forma a facilitar a análise da informa-ção;
– Deve ser possível saber que equipas estão a utilizar cada tecnologia; – A informação deve estar acessível a todos os colaboradores;
– As tecnologias devem ser classificadas com base na frequência de uso; – A visualização deve ser apelativa em termos de User experience (UX); • Casos de uso:
Figura 3.1: Casos de uso TT Technology Radar
Verificar quem esta a utilizar uma dada tecnologia: Através da ferramenta o utilizador deve ser capaz de visualizar as equipas que estão a utilizar uma dada tecnologia. Ao tornar esta informação transparente entre colaboradores, possibilitará a entre-ajuda entre equipas.
Verificar o estado de uniformização das tecnologias comuns: Através da ferra-menta o utilizador deve ser capaz de perceber claramente o estado de uniformização das tecnologias comuns, utilizando a informação para sensibilizar as equipas para a necessidade de convergência de tecnologias.
Atualização dos dados: O utilizador deve ser capaz de actualizar a informação sempre que necessário e as alterações devem ficar automaticamente disponíveis para consulta.
3.2 Estudo da maturidade das equipas da TT a respeito de CI/CD
Esta tarefa surge da necessidade de facilitar a análise da maturidade das equipas no que a CI/CD diz respeito. Uma vez finalizada é expectável que facilite a exposição da informação aos principais intervenientes e aos que devem poder decidir, justificadamente, sobre o investimento em recursos na área. Adicionalmente, os resultados permitirão às equipas identificar os eventuais pontos fracos, incentivando-as a melhorar continuamente.
3.2.1 Requisitos e casos de uso • Requisitos:
– Análise detalhada das componentes continuous integration, delivery e deployment; – Exposição da informação de forma organizada e de fácil entendimento;
3.3 Avaliação de ferramentas cloud para efeitos de CI/CD
Estando o mercado de desenvolvimento de software cada vez mais direcionado para a interco-nectividade de dispositivos através da Internet e considerando o emergente desenvolvimento de Software (SW) na cloud, como resposta à ineficiência das infraestruturas atuais, surge a necessidade de avaliar a viabilidade das soluções atualmente disponibilizadas. Esta avaliação passa por verificar se estão reunidas as condições necessárias e se se justifica o esforço para que ocorra a migração dos serviços atuais para a solução cloud.
3.3.1 Requisitos e casos de uso • Requisitos:
– Comparativo em termos funcionais entre as ferramentas utilizadas atualmente e as soluções cloud analisadas;
– Prova de conceito - configuração de um ambiente CI/CD, utilizando as ferramentas
cloud disponíveis;
CAPÍTULO
4
Análise do ambiente tecnológico
-Technology Radar
4.1 IntroduçãoTechnology radar é uma ferramenta de software que permite, para um dado ambiente (ex: empresa, mercado), observar as tecnologias que estão a ser utilizadas discriminando as que são mais populares das que estão obsoletas.
A grande vantagem desta ferramenta é que permite a verificação periódica das tecnologias emergentes e das que se podem vir a tornar obsoletas ou, simplesmente retratar uma vista geral sobre as tecnologias em uso. Estas características têm grande relevância, especialmente para empresas de software, uma vez que as tecnologias por si só estão em constante mudança, sendo de extrema importância estar atento às tecnologias que vão surgindo, de forma a ter uma maior capacidade de adaptação às tendências e necessidades do mercado [24].
Feita e disponibilizada a recolha da informação sobre as tecnologias em uso, a ferramenta produz um gráfico que é constituído por três estruturas principais:
• Quadrantes
– Representam a forma como as tecnologias são agregadas, sendo frequentemente consideradas quatro categorias: Linguagens e frameworks, Técnicas, Ferramentas, Plataformas.
• Anéis
– Representam a popularidade de cada tecnologia (ex: Nova, Intermediária, Avan-çada). De forma a determinar quando uma dada tecnologia pertence a um deter-minado anel, a frequência de uso é o aspeto principal a considerar.
• Marcadores
– Representam as tecnologias. Podem ser vistos como qualquer elemento que repre-sente um papel no processo de desenvolvimento de software.
Figura 4.1: Exemplo Technology radar
4.2 Arquitetura e implementação
Antes de mais, é importante frisar que não é possível utilizar a ferramenta original diretamente a partir da rede interna da Bosch (Bosch connect network (BCN)),devido a questões de segurança. Tendo em conta esta situação, tirando partido do facto desta ferramenta ser open
source, foi implementada uma solução personalizada, baseada num projeto de referência dentro
da empresa: Zalando project [25].
Resolvidas as questões técnicas, foram consideradas as treze equipas de desenvolvimento pertencentes à divisão da TT na localização de Aveiro.
A solução foi desenvolvida seguindo os passos seguintes:
• Recolha e análise das tecnologias usadas pelas equipas
– A recolha foi feita previamente e disponibilizada em vários ficheiros CSV com os dados relativos às equipas de desenvolvimento consideradas.
• Organização dos dados num ficheiro CSV estruturado
– Os dados foram organizados num único ficheiro de input seguindo a estrutura defi-nida. Neste processo foi também acordado o critério de atribuição das tecnologias aos anéis, tendo o mesmo sido baseado na frequência de uso de cada tecnologia. • Desenvolvimento da visualização
– Uma vez construído o ficheiro de input com toda a informação relevante, foi cons-truída uma visualização usando a biblioteca d3.js. Esta visualização foi inspirada num projeto interno, Zalando Project, ao qual foi acrescentada a funcionalidade de verificar as equipas que estão a utilizar cada tecnologia presente no radar.
4.2.1 Integração com o Docker
De forma a tornar o radar acessível a todos os interessados dentro da divisão, foi utilizada uma ferramenta de virtualização - Docker. De forma genérica, esta ferramenta permite que os seus utilizadores criem ambientes linux isolados (containers), onde se podem correr e testar as aplicações pretendidas, com a garantia de que as mesmas vão funcionar em qualquer outra máquina, independentemente das definições personalizadas que cada uma possa ter.
Uma das grandes vantagens do Docker é a existência de um repositório oficial - Docker
Hub- onde podem ser encontradas inúmeras imagens de máquinas pré-configuradas para os
mais diversos propósitos. Desta forma é possível descarregar a imagem que sirva os requisitos pretendidos e simplesmente corrê-la num Docker container.
Para o propósito do Technology Radar da TT, o requisito consistia em encontrar uma imagem de uma máquina com um servidor web configurado. Depois de uma pesquisa no
Docker Hub, foi encontrada uma que preenchia os requisitos impostos, tendo sido esta a opção
selecionada para disponibilizar a visualização num dado IP e porto. 4.2.2 Integração com o Jenkins
Uma vez concedido o acesso geral ao radar, o objetivo era obter um deployment automático do serviço de forma a que, sempre que detetada uma mudança no ficheiro de input com a informação das tecnologias, o mesmo fosse automaticamente atualizado em conformidade e disponibilizado para todos os interessados. Para este efeito foi utilizada uma ferramenta específica - Jenkins - e construída a respetiva pipeline que viabiliza o objetivo proposto.
A imagem seguinte ilustra a arquitetura utilizada.
Figura 4.2: Arquitetura TT Technology Radar
Pela figura anterior podem ser identificados três componentes principais: • Repositório de código - Bitbucket
– Repositório onde estão alocados todos os recursos aplicacionais. • Docker swarm
– Conjunto de máquinas disponibilizadas para alocar qualquer aplicação construída com recurso a docker containers. Nele são disponibilizados os recursos necessários para colocar o radar em funcionamento, sendo que o próprio radar também se encontra aí alocado.
• Repositório de imagens Docker - DTR
– Repositório privado de imagens Docker para onde será enviada a imagem do radar após esta ter sido construída.
Para um melhor entendimento do funcionamento do TT Technology Radar, serão descritos os três passos da pipeline adotada de acordo com a figura 4.2:
1. Qualquer atualização ao ficheiro de input com as tecnologias usadas é detetada automati-camente, a pipeline é despoletada e dado inicio à fase de checkout. Esta fase consiste na atualização dos recursos do projeto na máquina Jenkins a partir da qual será atualizado o serviço.
2. Na fase de Build and Deploy a imagem docker é construida de acordo com as mudanças verificadas e é enviada para o Docker trust registry (DTR).
3. Por último, na fase deploy service a imagem é descarregada a partir do DTR e é criado no Docker swarm o container onde a versão atualizada será disponibilizada para quem queira aceder ao serviço dentro da rede Bosch.
Figura 4.4: Resultado TT Technology radar - teams feature
4.3 Atualização do Technology radar
Durante as reuniões com as equipas sobre o modelo de maturidade, relativo a CI/CD, a informação sobre as tecnologias usadas foi novamente recolhida e o Technology radar atualizado em conformidade. Foram também identificados dois aspetos a melhorar:
1. Separação entre as tecnologias que servem propósitos comuns das que são especificas de cada área
2. Visualização complementar da categoria das ferramentas 4.3.1 Separação das tecnologias
Uma vez que o objetivo era standardizar as tecnologias que servem propósitos comuns a todas as equipas, tornou-se necessário ajustar a visualização para que esta facilitasse a distinção entre as tecnologias comuns das que são especificas de cada equipa ou área de trabalho. Por este motivo foi alterada a lógica de seleção dos anéis para cada tecnologia, tendo os seguintes conceitos sido adotados:
• Team specific
– Tecnologias especificas de cada equipa ou área de trabalho. • Common
– Tecnologias que servem propósitos comuns à maior parte das equipas de desenvol-vimento e que se ambiciona, por isso, que sejam uniformizadas.
• Common l1
– Tecnologias que são usadas entre zero e seis equipas, num total de treze equipas. • Common l2
– Tecnologias que são usadas entre sete e dez equipas, num total de treze equipas. • Common l3
– Tecnologias que são usadas entre onze e treze equipas, num total de treze equipas. Desta forma dentro das tecnologias que servem propósitos comuns, as que são mais frequentemente usadas aparecem nos anéis mais internos do radar, ao invés das tecnologias que são especificas de cada equipa que aparecem no anel mais externo do radar.
Figura 4.5: Technology radar update 4.3.2 Visualização complementar das ferramentas
A partir da primeira versão do radar verificou-se que as equipas de desenvolvimento estão a utilizar uma vasta diversidade de ferramentas. Por este motivo importava ter uma uma visualização complementar sobre as ferramentas e as suas agregações funcionais, de modo a colmatar a necessidade detetada.
TT tools distribution
A solução encontrada é baseada numa visualização em árvore, a qual permite evidenciar dados hierárquicos de forma dinâmica através da utilização de figuras geométricas, geralmente retângulos. Uma vez mais a biblioteca d3.js foi utilizada para este efeito, sendo o resultado final apresentado em seguida, juntamente com a descrição das suas funcionalidades.
Figura 4.6: Vista geral sobre as ferramentas
Figura 4.7: Ferramentas da categoria Code Analysis Testing
Esta solução permite aos seus utilizadores verem todas as categorias e ferramentas corres-pondentes, assim como o número de equipas que utiliza cada uma delas.
4.4 Discussão e resultados
Com o estudo do ambiente tecnológico atual, pôde verificar-se a não uniformização das ferramentas em uso, especialmente no que diz respeito aos processos de CI/CD. A situação encontrada afeta a agilização do processo de desenvolvimento, tendo sido o resultado prático
deste trabalho importante e notório. No final, as equipas mostraram-se mais sensibilizadas no sentido de adotarem ferramentas standard de forma a melhorar o entendimento entre os colaboradores, uniformizando o ambiente tecnológico. Por outro lado, reconhecendo a impossibilidade de uniformizar todas as tecnologias dadas as especificidades de cada área de trabalho, a transparência de informação proporcionada pela possibilidade de se saber exatamente quem está a utilizar cada tecnologia, permitiu que quem de interesse, saiba a quem recorrer sempre que necessite de ajuda.
CAPÍTULO
5
Modelo de maturidade
Neste capítulo pode ser encontrada uma descrição detalhada dos conceitos de CI/CD, razões pelas quais é importante medir o nível de maturidade em cada equipa de desenvolvimento, assim como os resultados e conclusões do estudo efetuado na divisão da Bosch TT.
5.1 Introdução
Antes de iniciar a discussão sobre o nível de maturidade das equipas é importante clarificar o significado dos conceitos que serão avaliados: CI/CD [26], [27].
Figura 5.1: CI/CD 5.1.1 Integração contínua - CI
O processo de integração continua consiste na prática dos desenvolvedores de software en-viarem constantemente as suas alterações para um repositório comum onde as mesmas são sistematicamente validadas através de diversos tipos de testes. O foco deste processo passa pela automatização de testes que são despoletados a cada alteração submetida para o repositório comum, garantindo desta forma que a todo o momento as alterações não violam a integridade do produto.
5.1.2 Entrega contínua - CD
Continuous delivery é uma extensão do processo de continuous integration. Nesta fase o
objetivo é ter sempre um artefacto de software pronto a ser entregue ao cliente. Isto significa que, para além da automatização dos testes é necessário ter um processo de release automático, onde tão frequentemente quanto o necessário, são construidos e versionados os artefactos de software com as alterações sucessivamente efetuadas.
5.1.3 Implementação contínua - CD
Continuous deployment é o último passo de automatização de todo o processo. Nesta fase
pretende-se que qualquer alteração efetuada que passe com sucesso os passos anteriores seja entregue diretamente ao cliente de forma automática, sem qualquer intervenção humana. Desta forma apenas um teste falhado previne que um produto inconsistente seja entregue ao cliente.
Figura 5.2: CI/CD - ciclo de vida 5.1.4 Relevância do CI/CD
Existem algumas razões pelas quais o processo de CI/CD é de extrema importância [27]: • Tempo de resolução de bugs reduzido
– Deteção antecipada de problemas, devido ao processo de integração continua. • Foco no desenvolvimento das funcionalidades dos produtos
– Uma vez que os processos de integração e entrega são automatizados, os desenvol-vedores não perdem tempo em processos operacionais e podem concentrar-se no desenvolvimento das funcionalidades dos produtos por eles desenvolvidos.
• Produto sempre pronto a ser entregue
– A qualquer momento os desenvolvimentos no produto de software estão prontos a ser entregues ao cliente como um artefacto plenamente testado de acordo com os requisitos definidos.
Os pontos acima mencionados resultam em duas grandes vantagens a nível de competitivi-dade para as enticompetitivi-dades que adotem as metodologias de CI/CD:
1. Menor TTM, uma vez que as atualizações ao produto seguem para o cliente com maior frequência
2. Redução dos custos de mudança, sendo que o desenvolvimento é feito de forma incremental possibilitando um rápido feedback por parte dos stakeholders.
Figura 5.3: CI/CD - Vantagens
5.2 Como medir o nível de CI/CD
Para medir o nível de CI/CD entre as equipas da Bosch TT, foi utilizada uma ferramenta interna - MMCD que se traduz num questionário em que, após submetidas as respostas, é retornada uma visualização ilustrativa do nível de maturidade relativamente ao CI/CD.
As questões estão agrupadas em cinco categorias: • Build
• Testing • Culture • Deployment • Release
Estas questões estão separadas nos três níveis discutidos anteriormente: continuous integration, delivery e deployment, de forma a obter uma precisa e detalhada vista sobre a maturidade de CI/CD.
Figura 5.4: Questionário MMCD
Figura 5.5: Resultado MMCD
Depois de submetidas as respostas (Figura 5.4), a visualização correspondente é gerada (Figura 5.5), possibilitando a verificação dos seguintes aspetos:
• Etapas sequenciais até atingir o continuous deployment
– Através da visualização gerada, é possível verificar a existência de etapas sequenciais até ser atingido o continuous deployment, ou seja, a existência de níveis mínimos de integração e entrega continua para ser possível atingir o continuous deployment. • Nível de maturidade geral em cada etapa do CI/CD
– É possível ter uma visão sobre o nível de maturidade em cada uma das fases do processo de CI/CD, possibilitando a identificação dos pontos fracos no processo. • Pontos específicos de melhoria
identificar pontos concretos que deverão ser tidos em conta, de forma a otimizar o processo.
5.3 Discussão e resultados
Todas as equipas de desenvolvimento da divisão da Bosch TT foram consideradas para o estudo efetuado. Os resultados correspondentes foram analisados nas reuniões com cada equipa com o objetivo de sensibilizá-las para a importância da robustez dos seus processos de CI/CD, encorajando-as a melhorar de forma autónoma, através do acesso aos resultados, o que lhes permitirá uma análise mais detalhada dos aspetos a melhorar.
Este estudo permitiu, também, concluir sobre alguns aspetos genéricos quanto ao nível de maturidade das equipas relativamente a CI/CD.
Em primeiro lugar, os resultados revelam uma clara separação entre as equipas de desen-volvimento de software embedded e non embedded, as quais apresentam níveis de maturidade bastante distintos. Convém esclarecer que, desenvolvimento embedded remete para software que é desenvolvido para controlar qualquer dispositivo ou hardware específico (ex: micro-controladores), enquanto que non embedded é um desenvolvimento mais genérico, ao nível aplicacional (ex: web apps). Tendo em conta que os resultados são distintos entre os dois tipos de desenvolvimento, as conclusões serão também apresentadas em separado, conforme se segue.
5.3.1 Equipas Non embedded
Os resultados mostram que a maior parte das equipas tem já algum nível de maturidade na fase de continuous deployment. Contudo, o processo de CI/CD, como um todo, é ainda inconsistente, dado que as equipas continuam a ter pontos a melhorar nas fases de continuous
integration e delivery. À luz destes aspetos, tratando-se de um processo sequencial, é evidente
que as equipas devem focar-se em melhorar a qualidade dos seus processos de continuous
integration e delivery antes de passarem para a fase final - continuous deployment.
Aspetos comuns a melhorar:
Continuous integration
• Build
– A automação das builds durante o processo de integração é geralmente conseguida. No entanto, ainda há margem para introduzir melhorias nos seguintes aspetos: consideração de métricas (ex: duração, número de builds falhadas, etc) de forma a que o processo não fique estagnado ao longo do tempo; As builds devem falhar se a qualidade imposta por cada equipa não for atingida.
• Testing
– Deve existir uma clara separação entre testes unitários, de integração e funcionais, sendo todos estes níveis de testes feitos de forma automática.
Continuous delivery • Testing
– Testes não funcionais devem ser definidos e postos em prática de forma automática. • Deployment
– Todos os processos relativos aos projetos devem estar bem documentados.
– O setup de novos ambientes de teste deve ser feito da forma mais fácil e barata possível - provisionamento parcialmente automático.
• Release
– Geração automática de release notes.
– Todos os processos de suporte ao desenvolvimento devem ser tratados como código (pipeline e infraestrutura).
Figura 5.6: Resultado MMCD - Média das equipas Non Embedded 5.3.2 Equipas embedded
Para as equipas que trabalham em software embedded obter um nível elevado de CI/CD não é uma tarefa trivial, dado o vasto número de dependências de hardware existentes. No entanto, os resultados obtidos evidenciam que tal objetivo não é impossível de ser atingido, sendo muitas vezes a cultura e sensibilidade das equipas o fator determinante para a obtenção de resultados.
Na divisão da Bosch TT, a maior parte das equipas continuam a ter aspetos cruciais de integração a melhorar, havendo uma falha abrupta no processo de continuous delivery e
seguido pelo continuous delivery para que, passo a passo, se possa ultrapassar todas as dependências de hardware existentes, até atingir um processo de CI/CD estável.
Figura 5.7: Resultado MMCD - Média das equipas Embedded 5.3.3 Sumário
Tanto quanto foi possível perceber através dos resultados obtidos, as equipas non embedded continuam a debater-se com falhas no processo de continuous delivery e as embedded com o continuous integration. Ambas as equipas non embedded e embedded reportaram que uma das principais razões para a sua falta de maturidade no processo de CI/CD é a falta de recursos a nível de colaboradores dedicados e especializados na área de DevOps. Este é um aspeto importante a ter em consideração, de forma a evitar a sobrecarga dos desenvolvedores de software com este tipo de tarefas. Em suma, é essencial garantir apropriados níveis de maturidade nos processos de CI/CD, de forma a assegurar entregas de software fiáveis e regulares e obter feedback coerente dos stakeholders. Concorrendo para que a empresa atinja os seus objetivos, será possível desta forma, atingir um menor TTM, mantendo ou até melhorando a qualidade dos produtos desenvolvidos.
CAPÍTULO
6
Soluções cloud
A procura pelas soluções de desenvolvimento em cloud surge da necessidade de encontrar resposta para os problemas detetados no processo desenvolvimento de software. Atualmente estes fatores representam um desafio a ultrapassar para que seja possível o aumento da produtividade e qualidade dos produtos Bosch, bem como os objetivos estratégicos da empresa. Nas próximas secções poderá ser encontrada uma análise dos problemas e motivações que levaram à procura das soluções cloud, assim como a descrição e as provas de conceito de algumas das soluções cloud disponíveis à data de criação deste documento.
6.1 Problemas e motivações
A Bosch, enquanto empresa tecnológica, ciente das necessidades e tendências do mercado de software, quer posicionar-se como líder do mercado da IoT (Figura 6.1) e em simultâneo melhorar os seus produtos de forma a que estes melhor correspondam às expectativas dos seus clientes.
Os seguintes aspetos foram identificados como entraves ao alcance dos objetivos acima descriminados:
• Inexistência de infraestrutura Information technologies (IT) adequada para trabalhar eficientemente com a Internet
– Conforme se pode constatar, os desenvolvedores de SW debatem-se com bastantes dificuldades nos acessos a recursos externos à BCN. Com as ferramentas atuais (Figura 6.2), são necessárias várias configurações adicionais para que o acesso ao exterior seja garantido. Tais configurações envolvem procedimentos demorosos, tornando o trabalho dos colaboradores menos produtivo e incapaz de dar resposta às necessidades do desenvolvimento IoT, onde os dispositivos estão interligados através da internet.
– De acordo com a análise efetuada através do Technology radar, os desenvolvedores não utilizam uma cadeia de ferramentas standard para CI/CD que torne o processo de desenvolvimento de software eficiente para todos os colaboradores.
• Os desenvolvedores de SW vêem reduzida a sua produtividade
– Os colaboradores vêem limitada a sua capacidade de solucionar os problemas existentes.
Figura 6.1: IoT
Figura 6.2: Ferramentas utilizadas atualmente
6.2 Bosch Development cloud
Como resultado dos problemas e motivações descritos na secção anterior, surge o desenvolvi-mento do BDC. Esta é uma solução cloud, desenvolvida pela Bosch, que pretende dar resposta aos problemas identificados, apresentando-se como um substituto das tecnologias utilizadas atualmente para o desenvolvimento de software (Figura 6.2).
Inserindo-se dentro do ecossistema Azure, esta ferramenta propõe as seguintes característi-cas:
• Ferramentas 80% pré-configuradas e interligadas
• Deployment totalmente automatizado: cadeia de ferramentas CI/CD na cloud
6.2.1 Cenário atual
Com as características anunciadas, seria expectável que os desenvolvedores tivessem acesso ao mesmo conjunto de ferramentas e conseguissem facilmente colocar os seus projetos num processo de continuous deployment. No entanto, sendo que o BDC é uma ferramenta ainda em desenvolvimento, o cenário ainda não é o ideal, uma vez que parte das funcionalidades anunciadas ainda não estão disponíveis.
Figura 6.3: Arquitetura do BDC
O diagrama da Figura 6.3 ilustra a arquitetura do BDC, onde é possivel observar que este é composto por duas estruturas principais:
• Ambiente especifico de projeto - Labs
– Os Labs são um ambiente cloud privado de cada equipa, onde são alocados os recursos específicos de cada projeto. À data de criação deste documento, estes ecos-sistemas providenciam apenas a criação, parcialmente automatizada, de máquinas virtuais Linux e Windows.
• Serviços partilhados
– Serviços partilhados entre os ambientes privados de cada projeto (Labs). Atualmente disponibilizados: GitHub Enterprise, Jfrog Artifactory.
