Come migliorare il mio flusso di lavoro (git, symfony, compositore, pergola, grugnito)?

3

È tempo di migliorare il mio flusso di lavoro . Non ho mai avuto la responsabilità di creare l'infrastruttura, gestire git, versioni o rilasci. Per me è stato semplice spingere / tirare la maggior parte del tempo e penso che il flusso di lavoro non fosse allo stato dell'arte. Mi piacerebbe cambiarlo e visto che ci sono tanti modi, mi piacerebbe che tu mi aiutassi, trovandone uno buono.

Ho letto su buone soluzioni qua e là (ad esempio Docker), ma sono un po 'perso a causa della varietà. Sono interessato a qualcosa di stabile, intelligente, semplice.

Sto gestendo manualmente versioning ( git tags ); Esempio: Versione 1.2.3 (1 = versione principale [modifiche enormi], 2 = versione minore [caratteristiche], 3 = livello patch [correzioni di bug]) . Non sto usando i numeri di build . Dovrei, perché? Non riesco a vedere il vantaggio finché lavoro da solo o in un piccolo team su codice privato.

Ambienti :

  • Sviluppo (dev): locale
  • Test (test): online
  • Produzione (prod): online

Quando ho una nuova versione o un commit testabile, lo installo nell'ambiente di test; non appena viene dichiarato stabile, faccio lo stesso per prod.

Uso bower (dipendenze) e grunt (compiti) per lo sviluppo frontend, ma lo faccio solo con dev -environment.

Flusso di lavoro per un progetto normale :

  1. init external git repository
  2. clone vuoto git repository localmente
  3. Installa pacchetti (Symfony, ecc.) tramite Composer
  4. Configura i pacchetti ( config.yml )
  5. Crea parameters.yml locale
  6. Sviluppo (dev)
  7. Clonazione (test / prod)
  8. Crea parameters.yml per test / prod
  9. composer install / composer update
  10. Forse eseguendo alcuni script php bin/console ...

Problema : configuro (4) i pacchetti installati (3) localmente, ma non spingo la directory vendor . Quando installo i pacchetti (8, composer.json ), ricevo degli errori, perché config.yml ha configurazioni per pacchetti ancora non installati.

La mia soluzione attuale è caricare manualmente la directory vendor per la prima installazione, per evitare questo conflitto. Non mi piace la soluzione. Come migliorare il mio flusso di lavoro?

    
posta Mr. B. 05.10.2016 - 15:59
fonte

1 risposta

2

Per config.yml, una variabile di ambiente sarebbe una configurazione più moderna:

# app/config/config.yml
parameters:
    vendor: '%env(VENDOR)%'

Avere un secondo file yaml con una directory predefinita eviterebbe l'errore:

# config/default.yaml
parameters:
    env(VENDOR): '/mnt'

Riferimenti

risposta data 17.04.2018 - 01:18
fonte

Leggi altre domande sui tag