Angular & Spring Boot Pipeline – Part I
In this micro-series of tutorials, I will be discussing a full blown CI/CD pipeline for an Angular front end application & a small Spring Boot microservice. In this series, I will be using the following tools & technologies:
- Azure DevOps
In addition to the stated tools above, we’ll be using the following application development related technologies:
- Angular 8.x.x
- Angular CLI
- Spring Boot 2.x.x
So, without further ado, let’s assume that you’ve at least setup the repositories on GitHub or Azure Repo’s, etc, whatever your preference is. With regards to other tools, such as code analysis & dependency scanning, we’ll be using some of the following tools:
- OWASP Dependency Scanner
Of course, when it comes to creating a more complete & enterprise appropriate solution, I’d imagine that many more tools will be used to ensure that the application & the infrastructure will meet the necessary standards.
So, for the Angular source code application, here is the example that I’ll be using, then the DevOps page can be found here. Within my example, I will be making a build & deployment pipeline for branch & for master, the basic idea being that one of the pipelines will allow you to deploy to a development & testing environment, the other allows you to go through UAT, preprod & finally some production environment. Of course in my very basic example, the deployment pipeline may be somewhat immature since I won’t be setting up any environment(s) to deploy the code to.
Without further ado, let’s get started on the build pipeline for the Angular application. To start, within the DevOps environment, I’d suggest utilising the UI to some basic extent if you’re unfamiliar with Azure DevOps, an example being clicking on the “Pipelines” tab, then the “Create a Pipeline” button. This interface will illustrate a number of commands that you can use within your build pipeline, from CLI commands through to DevOps specific features, like publishing the build artifact.
First off, let’s start by ensuring that this pipeline never automatically runs, meaning that everytime that this pipeline has been run, it has been run manually. To do so, let’s set the trigger to exclude all possible branches, like so:
Easy & straightforward, wouldn’t you agree? Now, if you’re like me & you want to be sure that this pipeline is only ever able to run on some branch other than master, then the first task that you’ll want to run is the following:
This will ensure that this pipeline will always fail if somehow it’s being run the the source code for master. Simple, the next step would be to ensure that the Node environment has been setup as expected. This step is incredibly straightforward, it’s essentially just installing Node JS & Angular CLI.
Now, let’s just assume that the source code has built successfully & there’s no errors, the next part that I’d advise you do is to copy the relevant files over to the artifact staging directory. Of course, this will vary depending on many things, such as what you plan to do with the application, etc, in this instance, let’s just put this code on some mock docker container registry.
As you can see above, since this is the branch pipeline, when pushing to the container registry of choice, we’ve given this docker build a tag of alpha, this is just used to see a distinct difference between master & branch. You could take this another step further & get the of the npm project & include that in the tag if you wish. However, for the time being, I’m going to keep these examples as basic & primitive as possible.
This brings me onto a step that I’ve not quite yet covered, is pipeline variables, how you define pipeline variables, etc. It’s very straightforward, however, I will be going over that in my next tutorial where I go over the implementation of the master pipeline, I can also talk about the differences that’s involved between a branch pipeline & a master pipeline which may be of concern.
P.S. If you haven’t guessed, a pipeline variable is accessed using the following syntax: