Post Top Ad

Your Ad Spot

sábado, 1 de agosto de 2020

CI / CD para monorepos

Al crear aplicaciones sin servidor como una colección de servicios sin servidor, debemos decidir si vamos a insertar cada servicio individualmente en nuestro sistema de control de versiones, o agruparlos en un solo repositorio. Este artículo no entrará en detalles sobre cuál es mejor o no, pero todas nuestras publicaciones hasta ahora parecen mostrar ejemplos de servicios almacenados en repositorios individuales.
Lo que este artículo se va a demostrar, sin embargo, es que el despliegue de servicios desde una única monorepo es fácilmente factible dentro solución Marco de Pro sin servidor CI / CD.

Empezando

It would be great if you could follow along, even if you do not have your very own monorepo to play with. So here is one you can use. It's a little demonstration repo you can clone from Github and use in your own Serverless Framework Pro account, just change the org and app values in each of the four services to match one of your own.
NOTE: Serverless Framework Pro has a generous free tier so you don't need to worry about not having a paid account just to try this feature out for yourself.
Once you've cloned the repo, made the requisite org and app edit, you just need to push that back into a repo of your own for us to continue.
The last step before we walk through setting up the monorepo deployment is to ensure that we have our connection to our AWS account all squared away, especially if you have a brand new dashboard account. This is done by going to profiles on the top menu, selecting the profile we will be using and making sure an AWS account is connected.
With that out of the way, lets get cracking!

Connecting to Github

Make sure you create the app within the org, using the same names you added to the services serverless.yml file as well; I have one I called monorepotest ... super original I know. But once I have done that, I open the app and I should have a handy dandy add service button to click on. Doing that gives me two option. I want to choose Deploy from Github. You should then see a button to connect to Github. Click it and go through Github's OAuth process to authorise Serverless Framework Pro to access the monorepo you are configuring. Once done and returned, you may or may not need to just refresh the page. When you see the image below we can move on:
Implementar desde github

Deploying our first service

Once we have that connection, we can use the Select a repo dropdown to choose our monorepo, and the base directory drop down now becomes available after a second or so. In this list we should see all the services we may want to deploy that are a part of this monorepo. If you are using the Github repo I linked to before, you can select servicea, and now we get even more options to choose from.
We have covered preview deploys in a previous blog post, so I wont go into detail here on them; we are going to skip configuring that for now.
Moving down to the branch deploys section, if you have not yet configured any kind of stage, you will be prompted to do that now. Just click through to create the stage and return to the deployment config when done.
In branch deploys, we point our specific git branch to the stage we want to deploy to. If you only have a master branch and one stage this will automatically be selected and you just need to confirm. At this point you can just save the configuration and you are all set up. Merge into the master branch or deploy directly from the deploy now button and a deployment to your AWS account should begin!
If you go ahead and do the same for all the other services in the monorepo, you will be fully setup with monorepo deployments to AWS; if code is pushed all services in the monorepo will redeploy. If you don't want all of them to redeploy every time ... read on.

More advanced configuration

Selective deployments
By default, if you have multiple services of a monorepo configured and you merge a change anywhere in that repo, all services will redeploy, just in case. There's no way for the system to know if there are any dependencies between the services so it cannot assume that only that one service that had a change should be redeployed.
However, you can configure it differently. If you open the CI/CD settings for one of the services and scroll down to expand the advanced settings section, you should see numerous options to help you maximise the efficiency of your CI/CD pipeline for a monorepo.
Configuración avanzada expandida
By default, the Always trigger a deployment option is selected and means that this service will always be redeployed with any change to the git repository, even if there were no changes to the code of this service. If you only want this service redeployed when its own code is edited, uncheck the box and you should see something like:
Configuración de directorios de activación
Automatically, the directory of the current service is selected and you can just click save settings. From this point on, servicea will only be re-deployed when its own code is edited.
Dependency deployment
But what if you actually did have services that had dependencies on each other. So in the example with servicea, we could in fact link it to serviceb and configure it so that servicea will always be re-deployed when serviceb is also edited. Just by adding a reference to the correct service directory, I can ensure this will happen:
Service B added
I could of course do this for any number of services that servicea depends on and vice versa. But what if I have some kind of shared folder that servicea uses. Because we reference a directory structure in our configuration, you can point to any path in your monorepo to be watched for changes. In the example repo, we have a directory called shared that stores a number of classes and functions (or at least it could) that are re-used by multiple services. If I change anything in shared, multiple services need to redeploy.
I can accomplish this just by adding the path to shared:
Shared directory added
En la imagen de arriba, servicease desplegará en fusiones a Github si se detectan cambios en los directorios serviceaservicebsharedY puedo configurar cualquier servicio con cualquier disposición específica de dependencias que necesite, brindándome una gran flexibilidad para implementar lo que necesito en las circunstancias correctas.
Las implementaciones de Monorepo son mucho más simples de administrar usando Serverless Framework Pro CI / CD. Pero si tiene algún comentario para nosotros o simplemente desea compartir, visite nuestros canales o foros de Slack y háganos saber. O incluso puede enviarme un mensaje de correo electrónico en Twitter si tiene alguna pregunta.

No hay comentarios.:

Publicar un comentario

Dejanos tu comentario para seguir mejorando!

outbrain

Páginas