How We Keep Sikepa Up and Running
When building a business-critical application there are some things to consider to ensure that the app will be reliable to user. Here is some ways that we’ve done to keep Sikepa services running and maintainable
#1: Server Environment
We are deploying the application inside virtual machines hosted in Google Cloud Platform. To ensure scalability, we split the application into two VM — one for application server and one for PostgreSQL database server. To make the deployment consistent between environments, we are utilizing Docker to containerize both our backend and frontend application.
Tips: for non-essential business process, we can utilize spot instances for cheaper infrastructure cost :)
The VM, especially the Database VM was not exposed to the internet. Instead, we are utilizing a reverse proxy to accept all traffic from the internet, checking its subdomain, and routing it to the correct host and port.
#2: Deployment Process
CI/CD process was all done with Gitlab CI hosted in Fasilkom Gitlab Server. This process were triggered right after a commit added to the “develop” branch. There are four deployment stages involved in the deployment process
1. Build
In the Build step we are building the Spring Boot application into JAR file. While building, pipeline will fails if there is any syntax error or build level error. The outcome of this process is an executable JAR file of the application
2. Analyze
In the Analyze process we are running all the unit tests defined in the code. After running all tests, the pipeline also shows the overall test coverage into the coverage badge in the Gitlab repository. If there are any tests that don’t passed the pipeline, the CI/CD pipeline will halts and developer won’t be able to merge the branch to its parent branch.
At the same time, the process also trigger a static code analysis. This process utilizes SonarQube which is hosted in Fasilkom server. As the outcome, we can see the code analysis result of every pipeline process inside the SonarQube dashboard. Currently we only use the static code analysis result to refactor our code, but the team is currently discussing if we can limit some number of code smells before a code can be merged to its parent branch.
3. PublishStaging
This pipeline is a part of the Continuous Delivery process which build the application into a Docker image with certain image tag uniquely assigned to the pipeline. After the image building process finished then the image will be published to the image registry. We utilize GCP image registry to store the Docker image.
4. DeployStaging
This step is the final step of deploying the application to our server. This process include a process to connect to the VM instance via SSH, trigger a Docker pull to pull the latest Docker image from the registry. After the pull process succeeded, the process will trigger the server to restart the container and the latest code will be running in the server.
Currently, we haven’t introduced any advanced deployment process, such as blue-green deployment to the process, so the deployment process will introduce some slight downtime on every process. As a part of the agile software development process, we will introduce blue-green deployment method when needed.
Conclusion
By introducing a CI/CD pipeline, team have an automated deployment process which makes development process faster as deployment process can be done quickly without involving any manual process.
Thank you for reading this blog. See you in another PPL blog series!
