-
Notifications
You must be signed in to change notification settings - Fork 0
Deployment Documentation
To build the Frontend one can simply follow the steps stated here. As example this is the command that should be used to build for iOS. Execute it from the code directory of the repository:
expo build:ios -t simulator --release-channel staging
Expo then handles the whole building process by itself. Depending on the current workload of the Expo Building-Engine the setup of the build takes around 20 minutes. The current workload of the Building-Engine can be seen here. The building status can be followed in the Expo dashboard of the respective user account.
This whole process is also automated via GitHub Actions using expo-github-action. The YAML file configuring the Action can be found here. After each published release, the action is triggered and starts to build the frontend app for Android and iOS. As soon as the build-process is finished, the builds (.apk for Android or .app for iOS) can be downloaded via the Expo.io dashboard of the organisation "Bikenest". The organisation was created to manage the Expo publishing without dependence on personal accounts, though anyone can be added or removed from the organisation (see also here).
Based on the current stage of the project, the build will not be published automatically to any of the app stores. To do that the documentation here will help. Another option could be to change the Expo project from private (currently) to public, then users could access the builds too and download them.
The Backend services are all containerized and can therefore be deployed either via docker-compose (easier, but advanced features like replication or load balancing won't be available) or via Kubernetes (harder to set up and modify but has a lot more functionality). Basic docker-compose and kubernetes YAML configuration files are available in the Backend folder. (Important: Environment variables will have to be adapted for production. Also the docker-compose-debug.yml file is using a dummy flask app for the Raspberry Pi server, which was necessary for testing without hardware access and some image names are not configured to look for the image from a public container repository.) To load the docker containers for the Production server, it is best to use a container registry. In our case it is enough to use public dockerhub repositories, but it would also be an option to use private repositories. Basically the container images have to be built somewhere and will then be uploaded to the container repository. From there anyone with access to the repository can download the image.
We automate the build and push process on release using Github Actions.
The deployment using Kubernetes has been tested with a Hetzner Cloud Server. More detailed instructions on setting up the deployment can be found inside the Backend README.md.
For testing purposes we have a dummy flask application containerized, that will also be started up together with the Backend, if the docker-compose-debug.yml file is used. This application won't try to access the hardware and will instead just mock everything. So for deployment of this version, you can have a look at how the Backend is deployed.
For the real version, that is able to interact with the Bikenest hardware, we do not use a docker container. Basically its just a plain python script, that can be copied together with the requirements.txt onto the Raspberry Pi. You then install the requirements (with a virtual environment and pip) and start the script. Now you have a running flask server, that will handle requests from the backend. Currently the IP Address of the Raspberry Pi has to be configured via a environment variable for the backend. Later on this should be automated (maybe via heartbeats from the raspberry pis to the backend).