Os servi¸cos da plataforma que est˜ao referenciados no projeto do servi¸co t- yugoup-tenant s˜ao necess´arios para que o projeto possa ser devidamente integrado na pipeline. Quer isto dizer que, para que seja poss´ıvel compilar o c´odigo do pro- jeto, seria tamb´em necess´ario integrar na pipeline o c´odigo de todos os projetos com os quais o Tenant tem dependˆencias ou referˆencias. Ser´a portanto necess´ario gerir v´arios reposit´orios e incluir todas as solu¸c˜oes das dependˆencias do projeto numa pasta, que posteriormente ser´a reorganizada, e s´o depois poder˜ao ser feitas as
opera¸c˜oes sobre o c´odigo. De seguida ser´a ent˜ao poss´ıvel integrar an´alise est´atica, restaurar as dependˆencias do projeto do servi¸co Tenant, fazer build ao projeto, exe- cutar testes unit´arios, testes de integra¸c˜ao/performance e, por fim, interpretar os resultados dos testes. Foi tamb´em necess´ario instalar um plugin para que se possam analisar v´arios reposit´orios em simultˆaneo.
Para o setup do ambiente do Jenkins foi utilizado um script semelhante ao da figura 4.18. Este script vai criar uma pasta (final) e uma subpasta (src), vai fazer clone aos reposit´orios que fazem parte da plataforma e, por fim, build ao projeto. Isto acontece porque, como dito anteriormente, s˜ao necess´arios todos projetos da plataforma Yugoup, que est˜ao referenciados no projeto t-yugoup-tenant, para que possa ser feita build ao servi¸co da Web API do Tenant.
Figura 4.18 – Script de setup
No Jenkins, d´a-se uma descri¸c˜ao `a pipeline. Em Source Code Manage- ment, selecciona-se o plugin Multiple SCMs e configura-se a liga¸c˜ao aos repo- sit´orios via SSH. Todos os reposit´orios que v˜ao ser adicionados `a pipeline v˜ao seguir a mesma metodologia. Primeiro ser´a inserido o URL do reposit´orio e ´e seleccionada a credencial de acesso por SSH e s´o depois ´e especificada a branch sob a qual ser˜ao feitas as opera¸c˜oes. Por fim, d´a-se um nome `a pasta onde ser˜ao colocados os ficheiros dos projetos (4.19). As configura¸c˜oes restantes ser˜ao idˆenticas, n˜ao existir˜ao Build Triggers, apenas ser´a eliminado o workspace antes de cada build.
Em Build, todos os build steps utilizados para criar o setup ser˜ao feitos `a semelhan¸ca do script que se pode visualizar na figura 4.18. `A semelhan¸ca do script, como dito anteriormente, foi criada um diretoria – final – e uma subdiretoria – src – para onde foram passados os ficheiros dos servi¸cos. Foi utilizado o robocopy para
copiar os ficheiros para a subdiretoria: $ robocopy project-name folder-path junta- mente com as op¸c˜oes /COPYALL /e /NFL /NDL /NJH /nc /ns /np (Microsoft, 2019c).
Figura 4.19 – Multiple Source Code Management
Fase de Build do projeto
As primeiras instru¸c˜oes na fase de build do projeto tenant s˜ao a instru¸c˜ao de arranque da an´alise est´atica e a instala¸c˜ao dos NuGet Packages presentes num reposit´orio online. Posteriormente ´e feita build `a solu¸c˜ao do Tenant (4.20).
Figura 4.20 – An´alise est´atica, Restore e Build
Depois de iniciada a an´alise est´atica e antes e antes de ser feita build `a solu¸c˜ao ´e executado um script que vai instalar todas as dependˆencias atrav´es da utiliza¸c˜ao de um ficheiro batch (.bat) desenvolvido pela equipa da Yugoup. Na fase de build da solu¸c˜ao – e ap´os o setup do ambiente – todas as solu¸c˜oes ser˜ao revistas pela an´alise est´atica. Isto acontece porque se est´a a fazer build `a solu¸c˜ao do Tenant em conjunto com as solu¸c˜oes das suas dependˆencias.
Build e Run dos testes unit´arios
Tamb´em `a semelhan¸ca daquilo que foi feito no cap´ıtulo anterior, os testes unit´arios ter˜ao de ser compilados (4.21) e executados (4.22) para que sejam gerados resultados. S´o depois se podem armazenar e apresentar estes resultados. O mesmo acontece com os testes de integra¸c˜ao e performance.
Figura 4.21 – Compila¸c˜ao dos projetos de teste
Figura 4.22 – Execu¸c˜ao dos projetos de teste
As instru¸c˜oes de execu¸c˜ao dos testes j´a s˜ao conhecidas e, como pode ser visto pela figura (4.23), antes da execu¸c˜ao dos testes de integra¸c˜ao ´e necess´ario executar outro script, atrav´es de um ficheiro batch (.bat), para remover o feed das dependˆencias do projeto. Resta parar a execu¸c˜ao da an´alise est´atica e pode ent˜ao proceder-se `a execu¸c˜ao dos testes de integra¸c˜ao e performance.
Figura 4.23 – Remo¸c˜ao das dependˆencias
Build e Run dos testes integra¸c˜ao e performance
Os testes de integra¸c˜ao e performance s˜ao compilados e executados (4.24) `a semelhan¸ca dos testes unit´arios. Na fase de Post-build Actions v˜ao interpretar-se os resultados de todos os testes em simultˆaneo.
Figura 4.24 – Compila¸c˜ao e execu¸c˜ao dos testes de integra¸c˜ao e performance
Um complemento interessante `a pipeline seria a gera¸c˜ao autom´atica de uma imagem de Docker do servi¸co t-yugoup-tenant. A imagem foi gerada e exposta numa porta p´ublica mas o seu processo de gera¸c˜ao n˜ao foi inclu´ıdo na pipeline. Apesar da aplica¸c˜ao ter sido publicada, o seu endere¸co n˜ao estava autorizado a aceder aos servi¸cos da plataforma Yugoup. Em baixo ´e apresentada a estrutura do Dockerfile que deu origem `a imagem do servi¸co e s˜ao delineados um conjunto de Next Steps para o futuro, caso a equipa pretenda integrar na pipeline o processo de gera¸c˜ao autom´atica da imagem atrav´es de um Dockerfile.