A dashboard for app connected to app direct. I've stayed pretty close to the ideals of a 12 factor app.
https://arran-app-dashboard.herokuapp.com
- Dockerize the artifact so that testing and deployment use the same artifact
- There is a bug in the war distribution. While the API components work as expected, the static dashboard resources do not resolve
- not implemented the openID integration
-
user@host:~/source-root$ mvn clean package
-
user@host:~/source-root$ java -Dserver.port=(DESIRED_PORT) -jar jar-dashboard/target/app-dashboard-(VERSION).jar
The application should now be deployed locally on the port you defined in the above command.
-
user@host:~/source-root$ mvn clean package -PJAR-AND-WAR
-
user@host:~/source-root$ cd war-dashboard;mvn cargo:run
-- OR --
-
user@host:~/source-root$ cp war-dashboard/target/app-dashboard-war-(VERSION).war (your_tomcat)/app-dashboard-war.war
Assuming tomcat auto deploy is enabled from the webapp location, then the war will deploy on your configured port on the /app-dashboard-war context
This is a Spring boot app that is continuously deployed to heroku on the URL described in the POM
The project is build practicing continuous delivery from the beginning and is described in the DSL
Git flow is being used to allow feature branches to be automatically integrated to the develop branch the moment they pass. Obviously the means tests must be provided before pushing to origin.
All changes wait on the develop branch until it is decided to cut a candidate branch. The Candidate will result in a versioned release which will be tested, followed by a migration to master and heroku
The command to start the app on heroku is in the Procfile and can be updated any time by changing the Heroku Procfile template. Currently there is only built in support for the version placeholder
Tests are all of a unit flavour, however I have made a clear separation between what are true unit tests and those that are integration tests. This separation has been expressed in the maven lifecycle by running all *Test.java files in the test phase and all *IntegrationTest.java files in the integration-test phase.
The jar is always built and tested by default with no additional effort.
The war only builds when the JAR-AND-WAR maven profile is used. The cargo plugin is bound to the pre-integration-test phase and deploys the packaged war for confirming the deployable
Single code base using gitflow and multiple version.
All dependencies are isolated especially SNAPSHOT intermodule dependencies. This can be see in the way the pipeline is built
The app comes with some configurable defaults, however the keys and environment specific items are configured on heroku
Besides the database the only service being used is appdirect which is being used as a service.
The pipeline has this at its heart
App is stateless except for the spring security session, though this can be swapped out got reddit
Self contained... except of course for the optional war component.
Stateless. If the app supported user authentication I would have used redis and not app session
Totally disposable.
The app code deployed locally, used on CI, and on heroku is the same. This could be improved by using docker.
Logs have not been used too much in this case.
No real admin processes.