In this series of blog posts, we are going to deploy a full-stack application to Azure, and learn how to set up many components efficiently, and in a cost-conscious way.

We are going to talk about Spring Boot and Angular, but also deployment automation with Azure Pipelines and Azure Web Apps, monitoring with Azure Insights, and performance tuning. And we will not be shy about money: we'll talks about budgets and cost, and try to have a very inexpensive setup that can scale when needed.

Here are the parts of this series:

Generating the application

As the creator and lead developer of JHipster, I'm going to use JHipster to generate a "full stack" application using both Spring Boot and Angular. Please note that this series of posts is not linked to JHispter: what we will do here should work in a generic way for all Spring Boot and Angular applications. We only use JHipster to speed up the development process, and also because it generates a non-trivial application for us, so we are not showcasing a simple "Hello, world" application, but one that is close to what you would expect in a real-life scenario.

You can either install JHipster by going to https://www.jhipster.tech/, or use JHipster Online to generate a full-stack application graphically. For this series of posts, we will use the latest release available at this moment, v6.0.1. We have chosen here a few interesting options for Azure:

We use MySQL, more specifically Azure Database for MySQL, as it is a very inexpensive option with Azure.

We do not use any Hibernate 2nd level cache. With Hibernate, if you want to be able to scale you will need to have a distributed cache, which is a bit complex to set up, so we will disable this for the moment. We will see on part 7 of this series how to use Azure Redis Cache to achieve this.

We have configured end-to-end tests with Protractor, so we will be able to test our complete application easily

The generated application has been pushed on https://github.com/jdubois/spring-on-azure, and you can see the initial commit corresponding to this part here.

Adding some business logic to the application

Now that a basic application has been created, we are going to add some business logic to it, in order to have a more "real-life" product. For this, JHipster proposes its "JHispter Domain Language", and we are going to use one of the provided samples, the "Bug Tracker". This will generate an application that looks a bit like the GitHub bug tracker: it's only generated code, and if you really want a working application, you will still need to code some business logic, but for this series of blog posts this gives us a complete application to play with.

Those entities can either be created using the JHipster command line, or graphically using JHipster Online, which will even be able to do a pull request to your GitHub project with those changes.

The commit corresponding to those new entities is available here.

Testing and running the application locally

Now that we have the full application ready, we can run its tests to see if everything is fine. You can run mvnw test to run the Java tests, and npm run test to run the front-end tests.

We can now run the application locally by typing mvnw -Pdev,webpack spring-boot:run , and opening our browser at http://localhost:8080/.

Lastly, let's run end-to-end tests with Protractor by running in another console npm run e2e . This will launch a browser that will run integration tests on http://localhost:8080/, proving that the whole application works well.

Below is a screenshot of the final application: in the next post of this series, we will create an Azure infrastructure so we can deploy it to production.