-
Notifications
You must be signed in to change notification settings - Fork 42
Project Infrastructure
This document outlines the infrastructure setup for the project, as depicted in the diagram. The process involves code development, continuous integration, and continuous deployment, culminating in the deployment of the application to a server accessible via api-csharp.boilerplate.hng.tech
.
2.2.1 Forking and Cloning the Repository
-
Developer forks the main project repository to create a personal copy (
Dev's Fork
). - The fork is then cloned to the local development environment (
Remote
).
2.2.2 Development and Push
- The developer makes changes in the local environment and pushes the updates to the forked repository on GitHub.
2.2.3 Creating a Pull Request
- A Pull Request is created from the forked repository (
Remote
) to the upstream development branch (Upstream Dev
).
2.2.4 Continuous Integration (CI) with GitHub Actions
- GitHub Actions are triggered by the pull request.
- The workflow includes:
- Build & Test: The code is built and tested automatically.
- If the checks pass, the pull request can be merged into the upstream development branch (
Upstream Dev
).
2.2.5 Merging to Main and Deployment
- Once validated in the staging branch, changes are merged into the upstream main branch (
Upstream Main
). -
GitHub Actions then trigger the Deploy action, which includes:
- SSH into the deployment server.
- Executing a Deploy Script to update the server with the latest code.
- The updated application is now live and accessible via
api-csharp.boilerplate.hng.tech
.
2.2.6 Proxy Management - The server interacts with a Proxy to route traffic to the appropriate endpoints.
We've made a very comprehensive and dynamic Bash script, located at scripts/initialize.sh
, that completely Initializes a given server, and get's it ready for the different deployment environments in use by this project. It takes as arguments the name of the project and the primary deployment domain name. The script's functions include:
- Updates the target server's package cache
- Ensures Redis is installed, and creates all the necessary users and instances
- Ensures Nginx is installed, and sets up proxy configurations for all the different environments
- Set's up HTTPS for all the different endpoints
- Ensures the Postgresql Database is installed, creates users, and databases with appropriate permissions for all the different environments
- Ensures the Dotnet SDK is installed
Ensures means that the script checks for active installations for all the different tools, and depending on presence or absence continues ahead or installs the tools.
We created deployment scripts for each of the different environments as pictured in the diagram above. Located in the scripts
folder, they're all named according to the environment they deploy to. The scripts build the application on the server and updates the service responsible for running the app to use the latest build. This way, what is live for the app is always the latest.
The scripts are named as follows;
-
dev-deploy.sh
-> deploys thedev
branch -
staging-deploy.sh
-> deploys thestaging
branch -
prod-deploy.sh
-> deploys themain
branch
4.1 Init Script
- Automates the deployment server's setup, ensures all dependency are installed and configured
4.2 GitHub Actions
- Automates the build, test, and deployment processes
4.3 SSH
- Secure method to execute the deployment script on the server
4.4 Deploy Script
- Script responsible for deploying the application to the server
4.5 Proxy
- Manages and routes incoming traffic to the correct application endpoint within the server
This setup ensures a streamlined workflow from development to deployment, leveraging continuous integration and continuous deployment practices to maintain code quality and reliability. The automated processes minimize the risk of human error and enhance the efficiency of the development lifecycle.