Vous souhaitez mettre en place une chaîne automatisée CI/CD qui compile votre app Ionic et qui la déploie directement sur Diawi, le tout avec Github Actions ?
Je vous explique comment faire dans cet article.
Lorsque nous travaillons sur un projet de développement logiciel, nous nous rendons vite compte que compiler, tester, et déployer le projet devient vite lourd et rébarbatif.
Ces dernières années les techniques de CI/CD -- Continuous Integration/Continuous Development (ou le terme courant pour définir l'automatisation des builds, tests et déploiement) fleurissent.
Nous allons donc nous y intéresser pour le déploiement d'un app Ionic automatisé par Github Actions.
---dab---
Dans cette article, nous allons voir comment :
Nous n'allons pas aborder le déploiement pour Android (qui est relativement simple une fois qu'on a fait iOS), le déploiement sur les stores (ce sera peut-être l'objet d'un nouvel article) ni les tests qui pourraient être fait en CI/CD.
Pour pouvoir suivre ce guide, vous devez :
Au préalable, vous devez avoir un projet Ionic avec une app mobile iOS :
Le guide se focalisera sur l'environnement de dev du projet.
Afin d'utiliser le CLI locale de la version d'Angular installé pour le projet, ajoutez le script suivant dans package.json
:
{
// ...
"scripts": {
"build-dev": "node ./node_modules/@angular/cli/bin/ng build",
// ...
}
}
Nous allons cette fois ci créer l'action Github qui nous permettra de compiler notre app lorsqu'on pousse notre projet.
Pour cela, créez le fichier .github/workflows/dev-jobs.yml
avec les lignes suivantes :
# Github Actions
# https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions
# Ici, on indique à Github que le job doit s'executer sur push de la branche dev
on:
push:
branches:
- dev
# On configure l'environnement des outils qui seront utilisés lors de l'execution de notre tâche
env:
NODE_VERSION: 16.x
JAVA_VERSION: 11.0.10
jobs:
# C'est notre job de build, qui s'occupera de build tout l'ensemble de notre app jusqu'à l'application final
build:
name: Build App
# Comme on devra compiler une app iOS, il est préférable d'utiliser une image système de Mac fourni par Github
runs-on: macos-latest
steps:
- name: Config - Use Node.js ${{ env.NODE_VERSION }}
uses: actions/setup-node@v1
with:
node-version: ${{ env.NODE_VERSION }}
- name: Checkout
uses: actions/checkout@v2
- name: Project - Install dependencies
run: npm ci
- name: Project - Build
run: npm run build-dev
# Ici, si nous voulons déployer notre app pour le web, nous pouvons traiter les fichiers disponible dans www.
A ce stade, nous avons un projet qui, une fois poussé sur Github dans la branche dev
, se compile et fournit les fichiers HTML / JS / CSS dans le dossier www
du worker....
Savez-vous comment gérer les droits sous système Unix (Linux / MacOS) ? Cette article vous aidera probablement...
En vrai, il y a de nombreux articles sur le sujet, aussi bien en anglais qu'en français. Cependant, toutes les articles ne se valent pas et je me suis donc dis que je vais créé celui là comme tip-sheet personnel. .
Sous système Unix, on a principalement à faire à 3 commandes pour gérer les droits d'un fichier ou d'un dossier:
ls -l
: pour lister les fichiers et dossiers avec leur droitchmod
: pour modifier les droits d'un fichier/dossierchown
: pour changer le propriétaire d'un fichier/dossier
---dab---
Pour lister les fichiers et dossiers, on exécute la commande suivante ls -l
. Ce qui donne le résultat suivant:
drwxr-xr-x 25 root wheel 800 21 jan 20:19 extra
-rw-r--r-- 1 root wheel 21648 2 déc 12:37 httpd.conf
-rw-r--r-- 1 root wheel 21150 4 avr 2018 httpd.conf.pre-update
-rw-r--r-- 1 root wheel 21172 22 oct 2018 httpd.conf~previous
-rw-r--r-- 1 root wheel 13064 2 déc 12:37 magic
-rw-r--r-- 1 root wheel 61118 2 déc 12:37 mime.types
drwxr-xr-x 4 root wheel 128 2 déc 12:37 original
drwxr-xr-x 4 root wheel 128 2 déc 12:37 other
drwxr-xr-x 3 root wheel 96 21 jan 20:19 users
Si on prend la première ligne:
drwxr-xr-x
sont les droits de l'élément.root
est le propriétairewheel
est le groupeSi on prends les droits d'un élément, on a :
drwxr-xr-x
|\ /\ /\ /
| | | |_ Droits des autres utilisateurs (o)
| | |
| | |_ Droits des utilisateurs appartenant au groupe (g)
| |
| |_ Droits du propriétaire (u)
|
|_ Type d'élément: d: un dossier, l: un symlink ou -: un fichier
Et pour chaque droit, on a:
– – –
(aucun droit)– – x
(exécution)– w –
(écriture)– w x
(écriture et exécution)r – –
(lecture seule)r – x
(lecture et exécution)r w –
(lecture et écriture)r w x
(lecture, écriture et exécution)Vous pouvez maintenant décoder ce qui est affiché.
Cette fois, je vous laisse consulter l'article suivant Gestion des droits sous Linux (chmod / chown), ce sera plus simple.
Pour ma part, le paragraphe Généralité m'aide beaucoup dans le sens où j'accède rapidement à l'information sans "Googlelisé" et m'évite de chercher pendant des plombs.
J'espère que cet article vous a quand même été utile, et je vous dis à plus pour le prochain !
---/dab---
]]>Savez vous ce qu'est un polyfill ? Comme j'ai mis un peu de temps à pouvoir faire fonctionner les polyfills dans Symfony, je vous explique comment les intégrer rapidement.
Un polyfill dans Symfony est du code qui permet d'avoir les fonctionnalités récentes de PHP sur une ancienne version que vous utilisez.
Par exemple, vous utilisez PHP 7.4 et vous souhaitez avoir les fonctionnalités de PHP 8.1, vous pouvez donc implémenter des polyfills pour avoir ces dernières.
Il existe également des polyfills dans d'autres languages, comme le Javascript par exemple.
---dab---
J'ai du utiliser les polyfills de Symfony car :
Je me dis donc : “avant d’aller trop loin avec le nouveau projet, je vais revenir à SF 5.4 (dernière LTS)” sauf que lui non plus ne fonctionne pas avec PHP < 8 (erreur avec str_starts_with
qui n’est disponible qu’en PHP 8 ).
Et c'est là donc qu'on me suggère d'utiliser les polyfills .
Pour toutes les versions de PHP et les divers fonctionnalités, il existe des polyfills dans symfony disponible ici: https://github.com/symfony/polyfill
Bien évidement, nous n'allons pas les utiliser tous. On va juste utiliser celles des plus récentes qu'on a besoin par rapport à notre version actuelle.
Imaginons que nous sommes en PHP 7.4 et que nous ayons besoins des fonctionnalités de PHP 8.0 et PHP 8.1, nous allons donc executer les commandes suivantes:
composer require symfony/polyfill-php80
composer require symfony/polyfill-php81
Néanmoins, pour qu'ils soient actif, il faut supprimer les lignes suivantes dans le fichier composer.json
:
"replace": {
"symfony/polyfill-ctype": "*",
"symfony/polyfill-iconv": "*",
"symfony/polyfill-php72": "*",
"symfony/polyfill-php73": "*",
"symfony/polyfill-php74": "*",
"symfony/polyfill-php80": "*", // <-- ligne à supprimer
"symfony/polyfill-php81": "*" // <-- ligne à supprimer
},
Comme j'ai mis un peu de temps pour comprendre le fonctionnement et l'intégration de cette feature, je vous le partage, bien qu'en lisant cette article la solution parait simple .
Mais croyez moi, quand on ne connait pas le sujet, on peut rechercher pendant longtemps une solution et tourner en rond...
J'espère que cet article vous a été utile, et je vous dis à plus pour le prochain !
---/dab---
]]>Cela fait un petit moment que je n'ai pas poster d'articles. Ces dernières années j'ai été très occupé. Bref, je pense que je reviendrais dessus un peu plus tard. Revenons à notre sujet principal, à savoir comment créer et utiliser une librairie localement en React ?
Je suis nouveau dans le game React, étant plutôt ciblé Angular à la base. Bien entendu, il y a des avantages et des inconvénients sur les 2 stacks.
L'une des choses qui m'est passé par dessus la tête avec React, c'est la complexité de créer une librairie que l'on peut réutiliser localement. Là ou avec Angular, c'est d'une simplicité.
Bon, je ne dis pas que c'est vraiment compliqué car pour quelqu'un qui maitrise Webpack / Rollup et tous les outils nécessaires à la création d'une librairie, cela doit être assez simple mais à mon niveau, ce n'était pas vraiment le cas.
Je vous donne donc ma solution afin de créer une librairie configurée de manière manuelle.
---dab---
Vous allez devoir initialiser votre package (librairie):
mkdir my-lib
cd my-lib
npm init -y
Organisez ensuite votre package comme suit:
my-lib
|_ src
| |_ components
| |_ index.js
|_ package.json
Rollup est un packager (comme Webpack) mais très utilisé en React.
Babel est un compiler Javascript.
Exécutez le script suivant pour installer Babel et Rollup:
npm i -D @babel/cli @babel/core @babel/preset-env @babel/preset-react @rollup/plugin-babel @rollup/plugin-typescript rollup rollup-plugin-delete rollup-plugin-dts rollup-plugin-peer-deps-external npm-run-all
npm i -D react react-dom
npm i @testing-library/jest-dom @testing-library/react @testing-library/user-event react-scripts
Dans package.json
, transférez react
et react-dom
de devDependencies
à peerDependencies
:
{
// ...
"devDependencies": {
"@babel/cli": "^7.17.10",
"@babel/core": "^7.17.10",
"@babel/preset-env": "^7.17.10",
"@babel/preset-react": "^7.16.7",
"@rollup/plugin-babel": "^5.3.1",
"@rollup/plugin-typescript": "^8.3.2",
"npm-run-all": "^4.1.5",
"rollup": "^2.72.1",
"rollup-plugin-delete": "^2.0.0",
"rollup-plugin-dts": "^4.2.1",
"rollup-plugin-peer-deps-external": "^2.2.4"
},
"peerDependencies": {
"react": "^18.1.0",
"react-dom": "^18.1.0",
}
}
Ajoutez le fichier .babelrc
:
{
"presets": ["@babel/env", "@babel/preset-react"]
}
Dans package.json
, ajoutez les lignes suivantes:
{
//...
"main": "dist/index.js",
"module": "dist/index.esm.js",
"source": "src/index.ts",
"scripts": {
"build": "rollup -c",
"build-watch": "rollup -c -w",
"start-playground": "cd playground && npm run start",
"i-all": "npm i && cd playground && npm i",
"dev": "npm-run-all --parallel build-watch start-playground"
},
"eslintConfig": {
"extends": [
"react-app"
]
},
"browserslist": {
"production": [
">0.2%",
"not dead",
"not op_mini all"
],
"development": [
"last 1 chrome version",
"last 1 firefox version",
"last 1 safari version"
]
},
//...
}
Ajoutez un fichier rollup.config.js
avec:
import babel from "@rollup/plugin-babel";
import typescript from "@rollup/plugin-typescript";
import external from "rollup-plugin-peer-deps-external";
import del from "rollup-plugin-delete";
import pkg from "./package.json";
import dts from "rollup-plugin-dts";
export default [
{
input: pkg.source,
output: [
{ file: pkg.main, format: "cjs", sourcemap: true },
{ file: pkg.module, format: "esm", sourcemap: true },
],
plugins: [
external(),
babel({
exclude: "node_modules/**",
babelHelpers: "bundled",
}),
del({ targets: ["dist/*"] }),
typescript({ tsconfig: "./tsconfig.json" }),
],
external: Object.keys(pkg.peerDependencies || {}),
},
{
input: "dist/types/index.d.ts",
output: [{ file: "dist/index.d.ts", format: "esm" }],
plugins: [dts(), del({ targets: ["dist/types"], hook: "buildEnd" })],
},
];
Dans votre projet Angular, vous en avez marre des chemins relatifs de vos import
, et souhaitez les transformer en chemin absolus (../../../components
=> components
)? Il existe une solution simple et rapide à mettre en oeuvre.
Bien souvent, on fait confiance à notre IDE, qui, en pratique, gère l'intégration des import
pour nous. Mais lorsque le projet est lourd et qu'on doit refactoriser du code, on se rend vite compte que les import
en chemin relatifs sont illisibles, et peuvent être compliqués à modifier.
---dab---
En réalité, la solution fonctionne pour un projet Angular, mais aussi pour tous ceux qui utilisent TypeScript.
Dans le fichier tsconfig.json
, ajoutez les lignes suivantes:
{
//...
"compilerOptions": {
"baseUrl": "./",
// ...
// ===> Code à rajouter
"paths": {
"@environments/*": ["./src/environments/*"],
"@components/*": ["./src/app/_components/*"],
// ...
}
}
// ...
}
Ainsi, on peut transformer nos:
import {environment} from '../../../../environments/environment';
import {PasswordModule} from '../../../_components/password/password.module';
En
import {environment} from '@environments/environment';
import {PasswordModule} '@components/password/password.module';
Magnifique !
Comme pour le TypeScript, la solution est assez simple, bien qu'elle soit propre à Angular. Ou du moins, il faudra faire des adaptations pour les autres projets (webpack, ...).
Dans angular.json
, ajoutez les lignes suivantes:
// ...
"architect": {
"build": {
// ...
"options": {
// ...
// ===> Code à rajouter
"stylePreprocessorOptions": {
"includePaths": [
"src/theme"
]
}
// ...
}
}
}
}
Ainsi, on peut transformer nos:
@import '../../../../theme/mixins';
En
@import 'mixins';
Doublement magnifique !
Configurer et utiliser des chemins absolus apporte plus de lisibilité et facilite la maintenance (refactoring par exemple) de votre projet.
J'espère que cet article vous a été utile, et je vous dis à plus pour le prochain !
Angular Workspace configuration
TS Config Reference
Import via Absolute Paths in Angular
---/dab---
]]>Lorsque vous développez un projet avec Angular ou Ionic, son organisation peut vite devenir un vrai casse-tête. Voici quelques tips pour mieux l'organiser.
Vous vous posez probablement la question "Où placer mon composant ?", ou encore "Comment nommer mon composant ?"...
Pour un petit projet, une librairie, c'est assez simple et évident. Pour des gros projets, on se creuse un peu plus les méninges. Car bien entendu, il faudra gérer l'imbrication des composants, la connexion entre eux, les services...
Il existe un guide proposé par Angular sur le code: Angular coding style guide. Cependant, tout n'y est pas.
Je vous propose donc une solution.
Avant d'aborder le sujet, je vous propose de faire un tour d'horizon sur les terminologies Angular, décrites sous un autre angle :
@Component
: désigne le composant principal d'Angular proposant la fonctionnalité souhaitée. Ex: Gérer un champ de recherche avec suggestion.@NgModule
: regroupe des composants, directives, services pour une fonctionnalité / un projet. Ex: Gérer une page de recherche avec un champ, la liste des résultats, un service pour accéder aux données, ...@Directive
: donne des fonctionnalités supplémentaires à un composant Angular ou du DOM. Ex.: Gérer l'affichage d'une image par défaut, si l'url chargée d'un composant <img>
comporte une erreur.Il existe bien entendu d'autres "decorator" que vous pouvez retrouver ici.
Un projet Angular est fait de Composants qui s'imbriquent les uns par rapport aux autres, afin de proposer l'App finale: pour faire simple, le composant est la fonctionnalité principale d'un projet Angular.
Cependant, pour mieux identifier chaque type de composant et avoir une meilleur organisation, on donnera des définitions supplémentaires :
mon-composant-page.page.ts
, définit un composant routable, c'est-à-dire une page de l'app accessible via une route.mon-composant-modal.page.ts
, qui définit un composant qui se superpose, c'est à dire une popup._mon-composant/mon-composant.component.ts
définit un composant abstrait, c'est-à-dire qui est exclusivement inclu dans un autre (aka la notion de abstract
).Vous pouvez ainsi donner une multitude de définitions en fonction de vos besoins, ce qui facilitera la compréhension du composant, sa recherche, sa finalité... et surtout qui organisera mieux votre projet Angular
Il est assez simple de définir une architecture des fichiers d'un petit projet. Pour un projet plus complexe, cela devient moins évident.
Voici donc une façon de structurer son projet Angular:
app: # Dossier de l'app
_components: # Tous les composants communs, ecclusivement inclus par d'autres. Ce sont généralement des modules indépendants.
header: # Composant de gestion de la toolbar en haut de page (Header)
header.component.ts
header.component.scss
header.component.html
header.module.ts
footer: # Composant de gestion du footer de page (Footer)
footer.component.ts
footer.component.scss
footer.component.html
footer.module.ts
alert: # Composant qui gére les alertes de l'app
alert.modal.ts
alert.modal.scss
alert.modal.html
alert.module.ts
# ...
_interfaces: # Toutes...
]]>
Dans une application moderne Ionic et/ou Angular, il est d'usage de gérer le multilingue. Mais on ne sait pas forcément comment s'y prendre et quoi utiliser. Les réponses sont ici.
Il existe trois solutions pour traduire son application :
Dans cet article, je ne vais pas entrer dans les détails d'implémentation, mais juste aborder les avantages et inconvénients de chaque solution.
Fonctionnalités | Angular Internationalization | Ngx-Translate | Transloco |
---|---|---|---|
Traduction des valeurs intégrées (dates, nombres, devises) | X | - | x |
Traduction dans les templates | X | X | X |
Traduction dans le code | - | X | X |
Changement de langue au moment de l'exécution | - | X | X |
Fonctionnalités | Angular Internationalization | Ngx-Translate | Transloco |
---|---|---|---|
Dépendances | @angular/localize | @ngx-translate/core / @ngx-translate/http-loader | @ngneat/transloco |
Compatibilité | - | Angular 2 - 10 | - |
Fonctionnement de la traduction | A la compilation | Via module Angular | Via module Angular |
Difficulté d'implémentation | Difficile | Facile | Facile |
Après avoir intégré les différentes solutions, je trouve que le module native d'Angular est assez compliqué à prendre en main et à comprendre. Il faut être familier du développement native sous Android et des fichiers de traductions XLIFF et XMB pour une meilleur compréhension. Cette librarie possède également une contrainte, et non des moindres: c'est à dire que la traduction se fait à la compilation : Vous ne pourrez pas traduire dynamiquement votre App.
Ngx-Translate est une librairie qui existe depuis la création d'Angular (la version 2) et a donc fait ses preuves. L'implémentation se fait facilement : on intègre un module et on utilise un service pour les traductions. Ces opérations sont donc familiées du développement avec Angular. Les traductions sont stockées dans des fichiers JSON, très simples à lire et modifier. La contrainte principale est que la librairie ne prend pas en charge la traduction des valeurs intégrées (dates, nombres, devises...)
Transcolo est le dernier-né, basé sur le système Ngx-Translate. Il a l'avantage de proposer l'intégration de plugins et une doc bien fournie. Le développement semble actif. On peut même traduire des dates et nombres avec le plugin Locale L10N. Bien qu'il soit nouveau, il est très prometteur et l'intégration se fait plus facilement que Ngx-Translate.
Si vous souhaitez intégrer une de ces solutions dans votre app, voici les guides :
Aprés avoir testé l'intégration et les fonctionnalités des trois solutions, Transloco est sans-doute la plus aboutie et la plus simple en terme d'intégration. Le plus compliqué à prendre en main est le module native d'internationalisation d'Angular.
Vous pouvez avoir un aperçu des différentes intégrations dans le projet démo que j'ai initialisé : https://github.com/clemdesign/ionic-i18n.
Je vous dis à plus pour le prochain article.
Liens utiles:
]]>Depuis Angular 7, on configure un projet via le fichier angular.json. Mais on peut aussi vouloir utiliser un plugin Webpack dans son projet. Voici la solution !
Angular se base sur Webpack pour construire son application. Cependant, depuis Angular 7, le CLI Angular utilise le fichier angular.json
pour les directives de compilation. Webpack, même utilisé, n'est plus accessible par nos propres plugins personnalisés.
Mais il existe une solution pour overrider les directives de compilation natives d'Angular : Angular Builders.
@just-jeb a développé un builder pour utiliser les fonctionnalités Webpack dans son application Angular.
Pour cela, il suffit d'exécuter la commande suivante :
npm i -D @angular-builders/custom-webpack
Puis, dans le fichier angular.json :
"architect": {
...
"build": {
"builder": "@angular-builders/custom-webpack:browser"
"options": {
"customWebpackConfig": {
"path": "./webpack-extra.config.js"
}
...
}
...
"serve": {
"builder": "@angular-builders/custom-webpack:dev-server"
"options": {
"customWebpackConfig": {
"path": "./webpack-extra.config.js"
}
...
}
Enfin, dans le fichier webpack-extra.config.js :
console.log('custom webpack config OK');
module.exports = {
plugins: [
]
};
Maintenant, vous pouvez vérifier que tout fonctionne avec ng build
et ng serve
.
NB: Les directives browser, server, karma et dev-server sont gérées par le builder Custom Webpack
Vous avez pu configurer Webpack dans Angular mais concrétement, cela donne quoi ?
Pour vérifier l'implémentation, testons le plugin InjectPlugin.
Exécutez la commande suivante:
npm i npm install webpack-inject-plugin
Puis, dans le fichier webpack-extra.json :
const InjectPlugin = require('webpack-inject-plugin').default;
module.exports = {
plugins: [
new InjectPlugin(function () {
return "console.log('InjectPlugin OK !');"
})
]
};
Exécutez la commande :
ng serve
Puis vérifiez dans la console le message InjectPlugin OK !
.
Ce plugin vous permet d'injecter du code à chaque construction de paquet.
J'espère que cet article vous a été utile.
Je vous dis à plus pour le prochain article.
Liens utiles :
]]>Il m'arrive de publier des guides pratiques, mais également d'en suivre d'autres sur différentes technos. En voici quelques un.
Je me dis que ces guides pourraient vous servir, et me permettra de les retrouver plus facilement également.
Créer une image docker avec Symfony 4 [FR]
Un guide intéressant de @Geotian pour comprendre et utiliser Docker avec un projet Symfony. Il y a 4 articles associés :
Utilisation de Docker [FR]
Un guide très pratique de @Xataz pour appréhender Docker. Voici le tutoriel : Utilisation de Docker
Angular 8 - Tutoriel et exemple sur l'enregistrement et l'authentification des utilisateurs
Un tutoriel très intéressant de @JasonWatmore pour intégrer un module d'authentification dans une app Angular. Mention particulière pour la structure et l'organisation du code, que j'adore et qui donne aussi des idées.
Voici le tutoriel: Angular 8 - Tutoriel et exemple sur l'enregistrement et l'authentification des utilisateurs et le Github.
Angular - Mise en pratique de RxJS dans Angular
Un turtoriel très intéressant pour appréhender RxJS et ses possibilités.
Voici le tutoriel: Mise en pratique de RxJS dans Angular
J'alimenterai ce post au fur et à mesure de mes découvertes.
Je vous dis à plus pour le prochain article.
]]>Lorsque l'on développe son projet Angular et/ou Ionic, on pourrait penser que le déploiement se fait facilement, mais en y réfléchissant bien, les solutions ne sont pas évidentes... Je vous explique tout dans cet article.
Comment distribuer facilement sa Web-App développée avec Angular / Ionic sur son serveur ? Différentes solutions existent, mais...
La solution standard consiste à copier les fichiers sur son serveur à l'aide d'un client FTP. C'est simple, mais pas très rapide, ni pratique. En effet, pour une App compléte, il y a des milliers de fichiers à transférer, une par une, ce qui peut prendre du temps. De même, une synchronisation (copier uniquement les fichiers modifiés, supprimer les fichiers inutiles...) peut être laborieuse.
Une autre solution consiste à utiliser les solutions de déploiement d'Angular. Cependant, cela limite à des environnements type Firebase, Azure... De plus, il faut intégrer les frameworks adéquats à son projet.
Ionic, quant à lui, propose la solution Appflow, sorte de Store des applications Ionic. Il faudra réintégrer Appflow sur son serveur, qui peut aussi se révéler long.
Ces solutions sont donc limitées et potentiellement longues à intégrer.
Pour les utilisateurs d'un système Unix, le plus simple et efficace est de créer un script qui synchronise les fichiers sur son serveur via SSH. L'outil rsync se prête parfaitement à cette tache.
Voici un petit script qui facilite le déploiement de manière automatique:
# Création de l'application en mode production
ng build --prod # For Angular App
ionic build --prod # For Ionic App
# Synchronisation du dossier www/ (ou dist/) vers le dossier de destination coté serveur
rsync -e ssh -avz --delete-after www/ user@ip_du_serveur:/dossier/destination/
L'option -e ssh
permet d'exécuter la commande avec SSH. L'option -avz
permet de garder la récursivité, en mode verbose, et compresser les fichiers pour le transfert.
L'option --delete-after
, quant à elle, permet de garder le dossier de destination identique à sa source.
Cette commande est simple et rapide si vous travaillez sur un système Unix et que vous possédez un accés SSH à votre serveur.
Je vous dis à plus pour le prochain article.
]]>