ENFR
Projet Personnel

Buildshare

Une application mobile React Native de distribution interne de builds Android, soutenue par un serveur Django qui gère les uploads, l'historique des releases et le traitement des artifacts.

Buildshare est un produit orienté testeurs, avec un backend conçu pour garder les uploads fiables et l'historique des releases auditable. Le choix principal: optimiser d'abord le workflow mobile, puis bâtir l'infra autour.

Vue d'Ensemble

Status

Développement actif

Role

Produit, backend et implémentation mobile

Stack

React Native, Django, DRF, Celery, Redis, PostgreSQL, Cloudflare R2

Updated

Mai 2026

Matrice de Fonctionnalités

Upload APK Direct

Évite les goulots d'étranglement côté serveur app

URLs R2 présignées + vérification serveur

Terminé

Timeline des Releases

Rollback rapide et traçabilité

Métadonnées de release + enregistrements immuables

Terminé

Traitement Asynchrone

Interface fluide pendant les jobs lourds

Workers Celery pour parsing, hashage, indexation

Terminé

Notifications OTA

Boucle de feedback testeurs plus rapide

Pipeline d'abonnement déclenché par release

En cours

Progression & Roadmap

v0.3

100%
  • Upload + registre des releases
  • Auth basique
  • Contrôle d'accès par projet

v0.4

70%
  • Vue diff des releases
  • Recherche améliorée
  • Nettoyage cycle de vie stockage

v1.0

30%
  • Export d'audit
  • Canaux de builds signés
  • Observabilité renforcée

Captures par Workflow

Buildshare screen 1
Liste des projets et contexte des releases
Buildshare screen 2
Détails release et métadonnées artifact
Buildshare screen 3
Navigation de timeline des builds
Buildshare screen 4
Workflow de téléchargement mobile-first

Défis Techniques

Gestion des gros uploads

Problem: Le transit d'APK via Django augmentait latence et pression mémoire.

Solution: Passage en upload direct vers le stockage avec URLs signées et validation callback.

Tradeoff: Plus de coordination entre client mobile, stockage et vérifications API.

Création de release fiable

Problem: Le parsing APK peut échouer sur des entrées malformées.

Solution: Parsing déporté dans des jobs Celery retryables avec états d'échec explicites.

Tradeoff: Consistance éventuelle nécessitant des états UI clairs.

Auditabilité vs vitesse

Problem: Accès rapide requis sans perte de traçabilité historique.

Solution: Métadonnées d'artifacts immuables avec historique de release et contexte acteur.

Tradeoff: Stockage un peu plus élevé et discipline de schéma plus stricte.

Performance & Fiabilité

Chemin Upload

Direct-to-R2

supprime le buffering serveur sur le chemin critique

Charge Lourde

Workers async

garde le cycle requête-réponse léger

Intégrité Données

Vérifs hash + metadata

évite les artifacts invalides en release

Leçons & Prochaines Étapes

  • Optimiser d'abord pour le workflow testeur; l'infrastructure doit servir ce parcours.
  • Traiter les états d'échec comme des cas de première classe côté API et UI mobile.
  • Prochaine étape: gouvernance des canaux de release et meilleure visibilité de latence jobs.
Ouvrir le dépôt GitHubRetour au portfolio