Codé en différent langages...

Utilisant des frameworks...

Des standards mal supportés...

Des navigateurs un peu butés...

Mais on aime les nouveautés

Obsolescence programmée

Transpiler du code

Optimiser du code

Vérifier le code

Une chaine complexe

Imbriquer les écosystèmes

Garantir la stabilité

Packager et livrer

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 ?

Old school

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

Pas très fiable...

Solutions logicielles

• Centralisées : Subversion, CVS
• Décentralisées : Git, Mercurial, Baazar, GNU Arch...

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é.

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 !

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

En Ruby ?

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 ?

{
  "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"
  }
}