Workflow

Automatisation et développement

Session 1

Stéphane HULARD
Consultant / Formateur

https://chstudio.fr
@s_hulard
http://github.com/shulard
s.hulard@chstudio.fr
s.hulard@univ-lyon2.fr

Un projet web aujourd’hui...

Codé en différent langages...

  • BackEnd: PHP, Java, Go, JavaScript, Ruby...
  • FrontEnd: CSS, Sass, Less, JavaScript, CoffeeScript, TypeScript, HTML, HAML...

Utilisant des frameworks...

  • BackEnd: Symfony, Laravel, WordPress...
  • FrontEnd: Compass, React, Angular, Express...

Des standards mal supportés...

  • Versions de JavaScript (ES2016, ...)
  • Propriétés préfixées en CSS
  • HTML5

Des navigateurs un peu butés...

  • Rythme de développement spécifique
  • Nouveautés versions par versions
  • Les applications développées doivent s'adapter et toujours fonctionner

Mais on aime les nouveautés

  • Sans contrainte lors du développement
  • Pour motiver les équipes en adoptant des pratiques innovantes
  • Pour la beauté du code écrit 😀

Obsolescence programmée

  • Être attentifs aux versions utilisées (langages, outils)
  • Un logiciel a un cycle de vie propre

Des outils existent !

Transpiler du code

TypeScript => JavaScript
ES2016 => JavaScript
Sass => CSS

Babel, lib-sass, ...

Optimiser du code

  • Compilation / Minification
  • Nettoyage

Uglify.js, PostCSS, AutoPrefixer, ...

Vérifier le code

  • Respect de norme, d'un schéma
  • Application de style de code
  • Tests unitaires et tests d'intégration

W3C, PHP_CodeSniffer, PHPCS Fixer, PHPUnit, Atoum, Behat, ...

Cycle de vie du projet

Une chaine complexe

Imbriquer les écosystèmes

  • Graphique (front, documents...)
  • Logique (code)
  • Statique (cache)

Garantir la stabilité

  • Tests unitaires
  • Tests d'intégration
  • Gestion des données, migrations

Packager et livrer

  • Qu'est-ce qui est le livrable ?
  • Comment le générer ?

Gestion de version

La gestion de versions (en anglais version control ou revision control) consiste à maintenir l'ensemble des versions d'un ou plusieurs fichiers (généralement en texte). Essentiellement utilisée dans le domaine de la création de logiciels, elle concerne surtout la gestion des codes source.

Pourquoi ?

  • Collaborer autour du code source
  • Avoir une trace de l'évolution d'un projet

Old school

  • Renommer les fichiers .old, .2
  • Dupliquer un dossier...

Pas très fiable...

Solutions logicielles

Centralisé ou décentralisé ?

Centralisé

  • Tout est stocké sur un serveur
  • Le dépôt sans le serveur est inutile

Si le serveur crash, plus rien...

Décentralisé

  • Chaque utilisateur dispose de sa propre copie
  • Chaque copie est indépendante
  • Plusieurs copie peuvent partager des modifications

S'impose comme standard grâce à la démocratisation de Git

Mais toujours un client

  • Logiciel sur le poste du développeur
  • Gérer la copie locale
  • Publier les modifications

Décentralisé ne veut pas dire que ce n'est pas partagé.

Concepts généraux

Une philosophie

Une multitude d'outils mais un seul besoin.

Repository / Dépôt

Conteneur utilisé par le logiciel pour stocker les versions.

Commit / Révision

  • Décrit une modification
  • Contient uniquement ce qui est utile pour la consolider

Branches

Différentes versions du code source indépendantes.

Tags

  • Version figée du dépôt
  • Attaché à un commit particulier

L'immutabilité du tag et primordiale !

Gestion des dépendances

Réutiliser

Du code est écrit tout les jours, fiabilisé et mis en open source. Utiliser ce code est un gain de temps considérable.

Fiabiliser

Bénéficier de l'expérience d'autres développeurs en utilisant un code testé et propre.

DRY Don't repeat yourself

  • Projets internes
  • Librairies / dépôts privées

Environnement

  • Les dépendances ne sont pas que des librairies
  • Version du language, fonctionnalités peuvent être testée
  • Permet de garantir la validité de l'environnement avant l'installation

Les outils

En Ruby ?

Gemfile
source "https://rubygems.org"
gemspec :name => "jekyll"

gem "rake", "~> 11.0"

# Dependency of jekyll-mentions. RubyGems in Ruby 2.1 doesn't shield us from this.
gem "activesupport", "~> 4.2", :groups => [:test_legacy, :site] if RUBY_VERSION < '2.2.2'

group :development do
  gem "launchy", "~> 2.3"
  gem "pry"

  unless RUBY_ENGINE == "jruby"
  gem "pry-byebug"
  end
end

En PHP ?

composer.json

{
  "name": "vendor/mon-project",
  "description": "Description.",
  "license": "proprietary",
  "type": "project",
  "require": {
    "php": ">=7.0",
    "laravel/framework": "5.5.*",
    ...
  },
  "require-dev": {
    "phpunit/phpunit": "~6.0",
    "squizlabs/php_codesniffer": "~3"
  }
}

En JavaScript ?

package.json
{
  "name": "project",
  "version": "1.0.0",
  "private": true,
  "dependencies": {
  "autoprefixer": "^6.3.7",
  "babel-plugin-transform-inline-environment-variables": "^6.8.0",
  "babel-preset-es2015": "^6.9.0",
  "babelify": "^7.3.0",
  ...
  },
  "devDependencies": {
  "nodemon": "^1.9.2",
  "parallelshell": "^2.0.0",
  "watchify": "^3.7.0"
  }
}