CICD with CircleCI and Heroku

Full Stack Software Development Blog

The final task to finishing off the server work is to wire up continuous integration and continuous deployment (CICD). I already have the CI piece of it working (see previous blog). Now to do the CD piece.

Step 1. Deploy Spring Boot application to Heroku

I followed the steps in the getting started on Heroku with Java tutorial.
See https://devcenter.heroku.com/articles/getting-started-with-java

The only thing of interest is the Procfile

web: java -jar application/target/texastoc-application-1.0.jar --server.port=$PORT --spring.profiles.active=test com.texastoc.Application

As you can see the Spring Boot application is run as a jar.
Set the server port as instructed by Heroku.
Set the spring.profiles.active to test so the it would use the embedded H2 database (for now).

Step 2. Integrate CircleCI to deploy to Heroku

Next I followed the CircleCI instructions to integrate with Heroku.
See https://circleci.com/integrations/heroku/

First I had to set a couple environment variables

• HEROKU_APP_NAME
• HEROKU_API_KEY

The big change is in the .circleci/config.yml file to deploy after building.
See https://github.com/gpratte/texastoc-v2-spring-boot/blob/master/.circleci/config.yml

Step 3. Spring Actuator

I needed to verify the deployment. What better way than to add a new endpoint (or two) to the server, push to github master and then curl the endpoint on the server deployed to Heroku.

I added Spring Actuator and curled the health endpoint.
See https://docs.spring.io/spring-boot/docs/current/reference/html/production-ready.html to know more about Spring Actuator.

JWT Auth for Spring Boot

Full Stack Software Development Blog

I took what I learned in my last blog about JWT Authentication and Authorization and applied it to my Spring Boot server application.

Most of the time was spent updating the integration tests. Almost every endpoint now requires authentication. The test were enhanced to login a player which returns a token. The token is then passed in the HTTP Authorization header.

Another departure from the proof of concept in my last blog is to

• use the player table instead of the user table 
• use email instead of username

See branch 37-jwt-auth at TexasTOC v2 Spring Boot

JWT Authentication and Authorization with Spring Security

Full Stack Software Development Blog


Worked through how to implement Authentication and Authorization (A&A) using JSON Web Token (JWT) with Spring Security.

Instead of blogging about it here I put together a proof of concept (POC) in github. The readme tells all.

See the https://github.com/gpratte/jwtauth repo.

CircleCI for continuous integration

Full Stack Software Development Blog

Using the free plan for CircleCI to build and run tests.

Here were the steps I followed

Chose the CircleCI free plan and use my github credentials to log into CircleCI.

Chose the texastoc-v2-spring-boot github repo for CircleCI to use. CircleCI added a key to this repo.


Followed the CircleCI directions to

• add a .circleci directory to my project.
• add a config.yml in the .circleci directory for a Java maven project

Now when I push to any branch CircleCI it downloads dependencies, compiles and run the tests.

Of course there were problems :)

Problem 1

My Java project is split into two modules: application and integration. That way I keep my integration tests separate from the application code. The integration module has a dependency on the application module.

I did not have a problem running the tests locally either in IntelliJ or using maven on the command line. But CircleCI choked on the integration module having a dependency on the application module. CircleCI actually wanted the application module as a library for the integration module to use.

I changed the config.yml so that the application module created a library.

Problem 2

When CircleCI attempted to run the test there was an obscure error.

I followed the instructions to add an ssh key to github which allowed me to run CircleCI in ssh mode. I was able to ssh into the build and look at the dump file. I googled the error and found a workaround that I added to my maven pom.xml.

Of course I added a comment to the pom.xml to a link to the stackoverflow solution to the file.

https://stackoverflow.com/questions/50661648/spring-boot-fails-to-run-maven-surefire-plugin-classnotfoundexception-org-apache

Server APIs coded

Full Stack Software Development Blog

Finished coding the logic for the server APIs (or as finished as any API is before the client starts calling it).

In one stretch of 10 days wrote 5000 lines of code (loc). 3000 were for the tests and 2000 for the application. Add code was done via TDD. JUnit for the Java classess/methods and Cucumber to exercise the APIs.

Now need to revisit the Authentication and Authorization (A&A). Since it is a REST service I will use a JWT token.

And of course the A&A will be done via TDD :)

Start Coding the Server

Full Stack Software Development Blog

Starting to code the server APIs.

See https://github.com/gpratte/texastoc-v2-spring-boot

I am following Test Driven Development (TDD) writing the business logic. Mocking out the persistence.

I am employing Cucumber tests for the endpoints. Persistence is provided by an embedded H2 in memory database.

As usual I number the branches. Here are the branches (copied from the readme).

branch 02-create-season

SeasonRestController POST endpoint to create a season.

New SeasonService.

Junit test (followed TDD) for the controller that passes through to the service. No persistence yet.

branch 03-create-season-repository

JdbcTemplate based SeasonRepository. Use the @MockBean for the SeasonServiceTest unit test.

branch 04-bdd-cucumber

Added cucumber BDD test. These tests bring up the server and use Spring's RestTempate to call the endpoint to create a season. Also uses an embedded H2 database. Uses a command line runner to create the season table.

branch 05-tdd-get-season

Implement the GET method on the season service using TDD.

branch 06-bdd-get-season

TDD and BDD

Full Stack Software Development Blog

I needed to get a better understanding of Test Driven Development (TDD) and Behavior Driven Development (BDD) testing.

The short explanation is:

Step 1. Both require a failing test to be written first in the form Arrange, Act and Assert (for BDD these verbs are Given, When and Then).

Step 2. Both require that as little code as possible be written to pass the test.

Step 3. Refactor the code if needed. The code that was written in step 2 may not be production worthy so make it so.

I wrote a poker hand comparator. I got as far as comparing two "high card wins" hands (i.e. no pairs, straights, ...).

The testing and coding is all explained in the github readme at the https://github.com/gpratte/tdd-bdd-experiment github repository.