Lignes directrices et orientation pour le déploiement de l'application¶
Objectifs du document¶
- Définir les attendus sur «comment builder et déployer l'application»
- Définir les étapes cibles
- Suivre l'avancement de la réalisation de ces étapes
Les attendus¶
On veut :
- minimiser la dépendance aux infrastructures tierces
- optimiser les temps de déploiement
- séparer les dépendances gérées par l'OS de celles gérées par l'application
Les étapes¶
- Séparer les dépendances infra système des autres
Globalement, on veut pouvoir faire abstraction d'apt, et plus particuliérement de la gestion des sources.list lors de la mise à jour. La gestion des sources.list peut être laissée à la main des clients donc dans ces cas là :
- on ne gère pas le source.list,
- on fait l'update/upgrade,
- on installe les logiciels.
On veut séparer ces étapes-là du reste pour pouvoir identifier le souci coté «sources.list» client.
- Embarquer toutes les dépendances de l'application dans la release
On veut diminuer nos dépendances externes (tout ce qui peut être renseigné dans un composer.lock ou package-lock.json, les sites externes) et réduire les opérations lors de la mise à jour (récupération des dépendances, construction de l'autoload, construction du front, etc)
- Rendre paramétrable l'URL de récupération de la release et de la configuration
Pour les clients coupés d'internet. Les scripts d'updates se basent sur les variables d'environnement (ou un choix par défaut) pour choisir où récupérer la release et la configuration. Ça va permettre aux clients d'héberger eux même le code et la configuration. Ca va aussi nous permettre dans le contexte de tests d'injecter beaucoup plus facilement la release