Github repository hosting the setup for the Digital Post Komponent.
- REST-Service: Service implementing the REST API that calling systems will use to send post
- PDF-Service: Service responsible for creating PDFs to be sent to Digital Post or Strålfors based on a template
- Dispatcher-Service: (Cron/Batch) Service responsible for figuring out which letters to send and which specific dispatcher service should send it. Also handles some sub-dispatcher errors
- Strålfors-Dispatcher-Service: Service responsible for having PDFs generated for a physical letter and sending it to Strålfors
- Digital-Post-Services: Github repository containing all relevant Digital Post services
- Digital-Post-Dispatcher-Service: Service responsible for having PDFs generated for digital post and sending it to Digital Post
- Enrollment-Service - (Cron/Batch) Service responsible for maintaining Digital Post enrollment lists
- Receipt-Service - (Cron/Batch) Service responsible for maintaining Digital Post receipts
- Common-Submodule - Github submodule containing the datamodel (SQL) and protobuf messages
- Flux - TCS test/prod repository
- Docker - Repository hosting a docker-compose setup
- Test-Data-Generator - Small service for sending test data
- Git for source control, and Github as source repository
- Github Workflow for continuous integration
- Java 21, Kotlin 1.9.22 and Go 1.22 as programming language
- Maven for building the Java/Kotlin services
- Makefile for easy scripting of Go build and run targets
- Docker for containerization
- Github Container Registry as docker image repository
- PostgresDB for persistence
- SpringBoot for Java/Kotlin projects
- protobuf and gRPC for communication
- Kubernetes as the infrastructure environment (hosted at Netic)
- kubectl CLI for accessing the Kubernetes cluster and viewing logs
We use Github Actions as our continuous integration flow, which triggers build and test runs for every PR created and on the main branch.
The Github workflow, which has been enabled at setup for each repository, will build the source code and run the available unit tests on each branch in the repo.
An overview and status of the workflow runs can be viewed in the Actions
tab of each project.
We take advantage of the ideas behind GitOps for working with CI/CD in the DPK project.
We use Github Actions and have added a workflow for continuous deployment. So when a new release has been created (manually, from Github Releases) of a given repository, it triggers the Github action for build and deployment of the service.
We use Github Container Registry to store the built release images of the services. The images which are built and are available can be viewed from the Packages
site on the repository (found in the right hand side of the Code tab).
The deployment process is maintained by flux using helm charts for deployng docker images to Kubernetes.
This section describes how to create a new release and publish the built docker image to Github Container Registry automatically:
We use Github actions for managing workflows in the DPK project. This means that the workflow named "Build and test code" is triggered when a pull request is merged to the main branch, and the workflow for building and publishing a Docker image of the service is triggered when a release is created.
Navigate to the Releases
section in the Code tab of your Github repo (in the right hand side of the page) and press the Draft a new release
button. Create a new tag, for example v0.0.7 and add a title for your release, for example Release v0.0.7
.
Check the check-box This is a pre-release
, if this is a pre-release version, and then press the Publish release
button. A release should be marked as pre-release if it's not production ready (or not intended to be deployed directly to production).