Deployment and Infrastructure
Relevant source files
The following files were used as context for generating this wiki page:
The Sovereign Communications (SC) project is a monorepo containing multiple platform applications (Web, Android, iOS) that share a common @sc/core library. The deployment and infrastructure are designed to support this structure, with distinct build, test, and deployment pipelines for each platform.
The infrastructure leverages automated CI/CD pipelines via GitHub Actions for testing and deployment, Netlify for hosting the web application, and Docker for potential local services. The overall goal is to ensure consistent, reliable, and automated delivery of all components of the SC platform.
Sources: CONTRIBUTING.md:7-25, V1_PRODUCTION_IMPLEMENTATION_PLAN.md:630-637
Build Process
The project uses npm workspaces to manage the monorepo. A key principle is that platform-specific applications (like web) depend on the shared @sc/core library. Therefore, @sc/core must be built before any dependent applications.
Sources: CONTRIBUTING.md:9-15
Build Scripts
A helper script, scripts/build-all.sh, is provided to automate the build process for all platforms in the correct order.
#!/bin/bash
set -e # Exit on error
# Build core library first
echo "Building @sc/core..."
npm run build -w core
# Build web application
echo "Building web app..."
npm run build -w web
# Build Android (if available)
if [ -d "android" ]; then
echo "Building Android app..."
(cd android && ./gradlew assembleDebug)
fi
# Build iOS (if on macOS)
if [[ "$OSTYPE" == "darwin"* ]] && [ -d "ios" ]; then
echo "Building iOS app..."
(cd ios && xcodebuild -scheme SovereignCommunications -sdk iphonesimulator build)
fi
echo "All builds completed successfully."
Sources: scripts/build-all.sh
Build Flow
The following diagram illustrates the dependency and build order of the main components.
This diagram shows that the web, android, and ios applications depend on the successful build of the core library.
Sources: CONTRIBUTING.md:32-60
Web Application Deployment
The web application is configured for continuous deployment to Netlify.
Sources: netlify.toml, web/DEPLOYMENT.md
Netlify Configuration
The netlify.toml file defines the build settings and environment for the production web app.
| Setting | Value | Description |
|---|---|---|
command | npm run build | The command to build the production web bundle. |
publish | web/dist | The directory containing the built static assets to be deployed. |
NODE_VERSION | "18" | Specifies the Node.js version for the build environment. |
Sources: netlify.toml:2-7
Manual Deployment
A manual deployment process is also documented, which involves building the project locally and using the Netlify CLI to deploy.
- Install Netlify CLI:
npm install netlify-cli -g - Login:
netlify login - Build Project:
npm run build(from thewebdirectory) - Deploy:
netlify deploy --prod
Sources: web/DEPLOYMENT.md:1-17
Local Development Infrastructure
The project includes a docker-compose.yml file, indicating the use of Docker for managing local development services. Although the file is currently empty, planning documents suggest it could be used for services like a lightweight signaling server for WebRTC bootstrapping.
Sources: docker-compose.yml, V1_READINESS.md:59-78
CI/CD Pipeline
The project uses GitHub Actions for its Continuous Integration and Continuous Deployment (CI/CD) pipeline. The pipeline automates linting, building, and testing across all platforms for every pull request and push to main branches.
Sources: CONTRIBUTING.md:162-172, E2E_IMPLEMENTATION_SUMMARY.md:104-140
Pipeline Workflow
The CI pipeline executes a series of jobs to ensure code quality and correctness before merging.
This diagram shows the flow of the GitHub Actions CI pipeline, from code push to final deployment.
Test Jobs
The E2E testing pipeline is split into multiple jobs to manage execution time and environment requirements.
| Job | Triggers | Platform | Description |
|---|---|---|---|
e2e-web | Every PR/push | Ubuntu | Runs basic web E2E tests on Chromium, Firefox, and WebKit. |
e2e-cross-platform-web | Every PR/push | Ubuntu | Runs web-to-web messaging tests. |
e2e-android | Nightly/Manual | Ubuntu + Emulator | Runs web-to-Android integration tests. |
e2e-ios | Nightly/Manual | macOS + Simulator | Runs web-to-iOS integration tests. |
Sources: E2E_IMPLEMENTATION_SUMMARY.md:108-139
Mobile Application Deployment
The deployment process for Android and iOS applications involves building release artifacts and submitting them to their respective app stores.
Android
- Build Release AAB/APK: Run
./gradlew assembleReleasefrom theandroiddirectory. - Sign Artifact: The release build must be signed with a release keystore.
- Upload to Play Store: The signed artifact is uploaded to the Google Play Console for internal testing, beta, and production release.
Sources: V1_READINESS.md:155-170, CONTRIBUTING.md:50-55
iOS
- Archive Project: Build and archive the project for release in Xcode.
- Upload to TestFlight: The archive is uploaded to App Store Connect for TestFlight beta testing.
- Submit for Review: After testing, the build is submitted for App Store review and release.
Sources: V1_READINESS.md:172-182, CONTRIBUTING.md:57-60
Production Configuration
The V1 production rollout plan specifies environment variables for configuring the production build. These are intended to be set within the deployment environment (e.g., Netlify UI or .env.production file).
VITE_SENTRY_DSN=https://...
VITE_ENVIRONMENT=production
VITE_API_ENDPOINT=https://api.sovereign.com
VITE_MAX_FILE_SIZE=104857600
VITE_RATE_LIMIT_MESSAGES_PER_MINUTE=60