Worblehat is a Java Spring-Boot based Case Study for the Applying Professional Scrum for Software Development training held by Andreas Ebbert-Karroum from codecentric AG.
- JDK 11+
- Docker / Podman
Maven comes bundled with the maven wrapper scripts, no need for manual installation before.
- Compile and install the application in the local maven repository with
./mvnw install
- Start the database:
- The easiest way is to fire up a docker container with
./worblehat-web/docker-db.sh
. - On Apple M1 Chips: We switched from MySQL to MariaDB because it's a drop in replacement and in version 10.5 compatible with the new ARM Chips. Just execute
./worblehat-web/podman-db-on-m1.sh
(In addition podman is used instead of docker).
- Run the application.:
- Either run
./mvnw -pl worblehat-web spring-boot:run
(will automatically compile & package the application before) - Or use your IDE to start the main class in worblehat-web:
de.codecentric.psd.Worblehat
- Access the application at http://localhost:8080/worblehat/
All tests are executed via JUnit, but can be conceptually divided in unit and integration tests. They are bound to different maven lifecycle phases, are executed by differen maven plugins, and follow a different naming scheme.
- Unit tests are run with
./mvnw test
- The maven-surefire-plugin includes all these tests by default:
<includes>
<include>**/Test*.java</include>
<include>**/*Test.java</include>
<include>**/*Tests.java</include>
<include>**/*TestCase.java</include>
</includes>
-
Acceptance tests are run by activating the required profile
./mvnw -P runITs verify
.Note: The
verify
lifecycle is executed beforeinstall
. Integration tests are only included, if therunITs
profile is activated. -
The maven-failsafe-plugin includes all these tests by default:
<includes>
<include>**/IT*.java</include>
<include>**/*IT.java</include>
<include>**/*ITCase.java</include>
</includes>
The acceptance tests spin docker containers for all required dependencies (Database & Browser) via Testcontainers.
In IDEA, you can use the CodeWithMe
Plugin to work together on the same piece of code, even if you're remote.
You should be able to run the application, as well as the acceptance tests not only via maven, but also from within the IDE.
Right-Click the class Worblehat
in worblehat-web
or AcceptanceTestsIT
in worblehat-acceptancetests
and run them.
In order to run single acceptance tests, your best option is to use the cucumber plugin in IDEA, with which you can start single Scenarios or Features from within the editor window.
With vs code, you can use the LiveShare feature to develop worblehat together. You can even share your port localhost:8080 so that everybody, who participates in the LiveShare session can access the application, even if it's only running on the hosts' computer.
If your build is taking too long, here are some strategies:
- add a webhook from your git repository to jenkins, in order to trigger a build immedeately
- Add
http://<teamserver-IP>/jenkins/git/notifyCommit?url=https://github.com/scrum-for-developers/<teamRepo>.git&delay=0
as webhook to your GitHub Repository
- Add
- try to reduce the amount of work in feature branches
- try to do steps in parallel
- try to reduce the amount of generated reports (maven-project-info-reports-plugin)
Spring Boot is running in development mode, this means that it restarts the context when new classes or resources are detected. Saving (and rebuilding) the class or html template should suffice in order for the browser to pickup the changes on reload. If you use a live reload plugin (like LiveReload for Chrome) your browser will automatically refresh, and you don't even have to reload the page.
It is possible in IDEA and code to start the class AcceptanceTestsIT
in debug mode, which enables you to
set breakpoints in the step definitions. This might help to understand, why things are not working as expected.
The source for the generated Changelog can be found at src/changes/changes.xml
. The XML file's syntax is documented with the maven changes plugin.
The version number should follow semantic versioning:
- Major version is currently
1
and should only change for breaking changes - Minor version should be set to the sprint number
- Patch version is incremental, if you choose to deploy multiple times within a sprint or need to publish a bugfix release. Start with 0.
To release for example version 1.2.0 follow these steps:
- Remove Snapshot version:
./mvnw versions:set -DremoveSnapshot
- Alternatively, you can use the interactive mode and just call
./mvnw versions:set
- Alternatively, you can use the interactive mode and just call
- Optional: Create a git tag and push the tag back to the team repository
git tag v1.2.0
git push origin --tags
orgit push origin v1.2.0
- Let jenkins build the release and deploy it to the test and production environments
- Bump the version for the next development iteration:
./mvnw versions:set -DnewVersion=1.3.0-SNAPSHOT