Configurazione dell'ambiente rispetto al rilevamento del dominio

3

Stiamo sviluppando un'applicazione 5 angolare che deve essere eseguita in diversi ambienti (dev, qa, int, uat, prod) e connettersi a API diverse a seconda dell'ambiente. Abbiamo tradizionalmente solo 4 ambienti e abbiamo un file di ambiente per ciascuno con le variabili di ambiente.

Ma ora con l'introduzione del 5 ° ambiente - integrazione (int) - Invece di aggiungere un canale di rilascio diverso in Octopus Deploy con una build diversa (che usa variabili d'ambiente), vogliono che l'app gestisca la configurazione rilevando il dominio nell'URL (in fase di esecuzione) e selezionare la configurazione in una struttura switch / case. per esempio:

let apiUrl = 'https://api.example.com/v2';
const location = window.location.origin;
switch(location){
  case 'https:dev.hostname.domain':
  apiUrl = 'https://dev-api.example.com/v2';
  break;
  case 'https:qa.hostname.domain':
  apiUrl = 'https://qa-api.example.com/v2';
  break;
  case 'https:int.hostname.domain':
  apiUrl = 'https://int-api.example.com/v2';
  break;
  case 'https:uat.hostname.domain':
  apiUrl = 'https://uat-api.example.com/v2';
  break;
}

Questo perché alcune persone stanno resistendo per modificare la configurazione dello strumento CI per aggiungere il nuovo canale di rilascio. Ma questo non mi sembra giusto, penso che le variabili di ambiente siano una soluzione migliore (viene utilizzato un file di ambiente diverso a seconda dell'obiettivo nella fase di compilazione). per esempio:

//QA environment file example
export const environment: Environment = {
  production: 'false',
  apiUrl = 'https://qa-api.example.com/v2',
  otherEnvVar: 'whatever',
}

E poi importando l'ambiente dove necessario:

//Some app file
import {environment} from '../environments/environment';
// ... my code ...

Ma quando cerco di spiegare la ragione per cui non riesco a pensare a nient'altro che questa soluzione mi sembra "brutta" (che non è una valida ragione). Quindi ora mi chiedo se ci sia un motivo valido per separare le variabili di ambiente dalla logica dell'applicazione.

Quale sarebbe la soluzione migliore e perché? o entrambi sono ugualmente validi?

    
posta Jorge Riv 09.08.2018 - 16:45
fonte

2 risposte

6

Devi assolutamente modificare l'elemento della configurazione per impostare correttamente la configurazione per l'ambiente piuttosto che provare a elaborarlo dall'URL in fase di runtime.

Dovresti utilizzare Ocotpus Deploy per sostituire le variabili di configurazione con le sue variabili di progetto con scope quando si distribuisce.

La vera ragione di ciò è che il codice non dovrebbe conoscere i potenziali ambienti in cui potrebbe essere distribuito. Dovrei essere in grado di distribuire il codice senza dover utilizzare un URL approvato.

Tuttavia, se stai cercando un elenco di argomenti contro l'idea ..

  • Un errore nel parametro url (come la mancanza del //) lo renderà non funzionale in quell'en
  • Gli URL dei server non attivi verranno esposti agli utenti dell'URL live
  • Gli utenti possono modificare facilmente l'intestazione host modificando il file hosts
  • Che dire dell'internazionalizzazione? .com .co.uk .ie ecc.
  • Se il dominio Api cambia, richiederà una modifica del codice piuttosto che una modifica delle impostazioni di configurazione
  • Per quanto riguarda le healthchecks dall'interno del loadbalancer, non entrano nel link
risposta data 09.08.2018 - 17:30
fonte
2

La risposta ovvia sarebbe una configurazione più semplice; se dici che devi aggiungere un altro ambiente, devi solo creare un nuovo file di ambiente, piuttosto che modificare e ricompilare il codice, o dire che hai bisogno di cambiare l'URL dell'API o cosa hai senza modificare il codice che puoi fare usando il file dell'ambiente.

Essenzialmente, in questo caso è meglio usare il file di ambiente come impostazione perché non è necessario gestire cose speciali al di fuori o modificare un paio di variabili, e questa tecnica ti permette di farlo facilmente

    
risposta data 09.08.2018 - 16:48
fonte

Leggi altre domande sui tag