Qu'est-ce que Smart Content Dependency Management™ ?

[LIVREBLANC] Dernière mise à jour par Joe Schaefer sur sam., 25 avr. 2026    source
 

arbre


Résumé

Gestion intelligente des dépendances de contenu™ concerne le cercle d’idées liées au soutien et à la facilitation des constructions incrémentielles, tout en restant fidèle au principe de normalisation du contenu — que permaliens doit être la source unique de vérité, quelle que soit la manière dont leur contenu est organisé dans l’arborescence source et les artefacts de construction résultants.

Cet article présente la https://sunstarsys.com/ site web comme étude de cas pour une démonstration des meilleures pratiques et une analyse des topologies de graphes associées.


Caveats

Cela n’a d’importance que lorsque vous devez peser les dépenses liées à la réalisation de builds de site complets chaque fois que vous devez modifier le contenu d’une page Web. Si votre site Web contient moins de 1K fichiers source, relaxez et lisez ce qui suit en tenant compte de vos besoins futurs. Vous avez choisi d’utiliser notre plateforme, conçue pour évoluer avec vous, pas contre vous. Pour la plupart des pages, ce document ci-dessous concerne les graphiques de dépendance de contenu dispersé pour les sites comportant plus de 1K pages.

Par exemple, l’Apache https://www.OpenOffice.Org Le site Web a pu construire ses fichiers 40K+ en utilisant la version originale d’Apache de ce système de construction, avec une prise en charge entièrement intégrée des builds incrémentiels — sans aucune dépendance configurée — en faisant un usage intelligent de la technologie SSI traditionnelle seule.

Par défaut, notre système de compilation crée uniquement les fichiers que vous avez modifiés, sans se soucier des dépendances intra-fichiers (sauf si vous les spécifiez dans %path : :dépendances — plus sur ce qui suit). Si le fichier que vous avez modifié se trouve dans la modèles/ ou lib./ Un build de site complet se déclenchera à la place.


Tissage du Graphique de dépendance de votre site Web ensemble

Mathématiquement, une Topologie τ\tau est une spécification complète des sous-ensembles open d’un espace XX, dont le but est d’indiquer les relations de proximité entre points xx de l’espace XX. Quand XX est un graphique, une topologie τ\tau pour XX correspond à la spécification des arêtes reliant les sommets du graphique entre eux (ici les sommets sont considérés comme les points de XX, et les bords de connexion déterminent les quartiers de ces points comme ensembles ouverts de base pour la topologie). Une topologie de graphique dirigée est essentiellement la même chose, mais incorpore une référence à une intégration topologique de (X,τ)(X,\tau) dans un plus grand espace topologique (Y,σ)(Y,\sigma) , où les connexions d’arête de l’imbrication sont représentées par des courbes directionnelles non-intersectantes (Jordanie).

Ce dernier concept est ce que nous allons utiliser lors de la discussion de la topologie du graphique de dépendance. τ\tau associé à l’espace XX des fichiers source sous le site contenu/ sous-répertoire (ici) (Y,σ)(Y,\sigma) est Rn\mathbb{R}^n avec sa topologie métrique pour n{2,3}n \in \{2,3\}et les bords de XX sont des courbes Jordan dirigées qui relient un fichier xXx \in X à son ensemble de dossiers sur lesquels xx dépend : {xXxx}\set{x^\prime \in X | x \rightarrow x^\prime}).

Avoir une compréhension claire du graphique de dépendance de votre site Web vous permettra de maximiser les performances de notre technologie de construction à grande échelle. Nous prenons les informations que vous fournissez à %path : :dépendances pendant le chargement de votre site web lib/path.pm créer une carte inversée des fichiers dépendants et utiliser cette carte inversée pour déterminer le corpus complet de fichiers à créer pour un fichier donné validation svn vous faites à notre système.

Il est important de noter que les relations de dépendance entre les fichiers source peuvent et doivent être entièrement capturées par le %path : :dépendances hash pendant la charge de démarrage du système de build de lib/path.pm de votre arbre source, c’est ainsi que les vues intégrées contenues dans notre SunStarSys : :Voir Le paquet Perl est destiné à fonctionner. Le walk_content_tree, archivé, et seed_file_deps fonctions utilitaires importées à partir de SunStarSys : :Util sont utiles pour construire le %path : :dépendances hash, avec prise en charge intégrée de la gestion d’un cache de dépendance pour accélérer les builds incrémentiels à grande échelle.

Voici cette partie de notre vie lib/path.pm:

our (%dependencies, @acl);

# entries computed below at build-time, or drawn from the .deps cache file

walk_content_tree {

  $File::Find::prune = 1, return if m#^/(images|css|js)\b#;

  return if -d "content/$_";

  seed_file_deps, seed_file_acl if /\.(?:md|ya?ml)\b[^\/]*$/;

  my $path = $_;
  utf8::is_utf8 $path or utf8::decode $path;
  state $count = 0;
  for my $lang (qw/en es de fr ru sv he zh-TW ar ko ja pt-BR/) {
    delete $dependencies{"/sitemap.html.$lang"} if ++$count <= 12;
    next if m!\.page/!;
    if (/\.md\.$lang$/ or m!/index\.html\.$lang$!) {
      push @{$dependencies{"/sitemap.html.$lang"}}, $path if !archived;
    }

    if (/^(.*)\.tex\.$lang$/ and -f "content$1.bib.lang") {
      push @{$dependencies{$path}}, "$1.bib.$lang";
    }

    if ($path =~ s!/index\.html\.$lang$!!) {
      $dependencies{"$path/index.html.$lang"} = [
        grep {utf8::decode $_; s/^content//}
        glob("'content$path'/*.md.$lang"),
        glob("'content$path'/*/index.html.$lang")
      ];
    }
  }
}
  and do {
    while  (my ($k, $v) = each %{$facts->{dependencies}}) {
      $dependencies{$k} = [grep $k ne $_, grep s/^content// && !archived, map glob("'content'$_"), ref $v ? @$v : split /[;,]?\s+/, $v];
    }

    open my $fh, "<:raw", "lib/acl.yml" or die "Can't open acl.yml: $!";
    unshift @acl, @{Load join "", <$fh>};
    my %cache;
    @acl = grep !$cache{$_->{path}}++, @acl;
    for (glob("content/*/index.md.*")) {
        next if /archives|categories/;
        s!/index\.md\.[^/]+$!!;
        push @acl, { path => $_, rules => {
             '@bloggers'  => 'rw',
             '@svnadmin' => 'rw',
             '*' => 'r',
        }} unless $cache{$_}++;
    }
  };

S’il vous plaît faire mull ce code pour des idées sur la façon dont vous voulez *votre site Web *pour travailler. Oui, il y a une certaine complexité raisonnable (impliquant à la fois les expressions régulières de Perl et le shell C UNIX de Perl). glob interfaces, d’une manière très précise) autour de la façon dont %path : :dépendances est construit dans ce fichier, mais au lieu de simplement voir cela comme un travail d’optimisation, au lieu de le regarder comme fournissant les ingrédients de base nécessaires pour construire des aspects majeurs de la topologie link d’une manière automatisée et générée dynamiquement.

Emplacement des entrées dans %path : :dépendances origine ? S’ils ne sont pas nés d’une invocation de walk_content_tree { seed_file_deps ... }, (qui plonge essentiellement dans les en-têtes et le contenu de vos fichiers source de démarque), alors ils sont simplement codés en dur dans lib/facts.yml au moment du chargement.

Les graphiques de dépendance cyclique sont la norme

Notre site se compose actuellement de 240 fichiers source dans contenu/. Voici un 85 sommets x 465 bords, représentation graphique dirigée bidimensionnelle défilable d’un instantané récent des dépendances de page en langue anglaise de notre site (utilisation de GraphViz point):

Dépendances linguistiques en anglais

Assez complexe, même pour un petit site comme celui-ci ! De nombreuses intersections de bord lors de la prise n=2n=2 (évitable en dimension) n=3n=3). Notons en particulier l’ensemble principal de dépendances cycliques denses dans les fichiers non archivés de notre site /essais/ répertoire, vers la partie inférieure-centre-droite du graphique, à quoi devrait ressembler le graphique de dépendance d’un bon site de blogs. Ces dépendances sont dessinées dans courbes rouges dans l’image.

Notez également l’interconnexion interne, essentiellement isolée, des éléments dans /Catégories/*/* et /archives/2022/11/*. Les seules dépendances externes impliquent un contenu non archivé dans /essais/*. C’est par design — les essais archivés ne devraient changer que adiabatically, peut-être uniquement pour des ajustements à leur Catégorie en-têtes. Aucune de ces modifications n’affecte matériellement le contenu préexistant, nous ne le suivons donc pas dans %path : :dépendances.

Bien sûr, notre Wiki d’Orion Enterprise n’a jamais eu de problèmes avec les dépendances cycliques.

N’est-ce pas seulement des hyperliens ?

Non ! En fait, la topologie link de votre site Web est une question entièrement distincte du graphique de dépendance de l’arborescence source. Un moteur de recherche va naturellement extraire la topologie link, mais n’a aucun aperçu du graphique dependency.

Voici un 240+ sommets x 3859 bords, graphique des yeux d’oiseau actuel du graphique topologie du lien en anglais pour notre site (utilisation de GraphViz twopi):

Pouvez-vous repérer bords rouges comme indiqué dans le graphique de dépendance ? Le graphique topologie du lien est qualitativement et quantitativement très différent du graphique dépendance (dramatiquement plus petit et moins interconnecté) illustré ci-dessus.

Comment la technologie SSI peut aider

Traditionnel <a href=”https://httpd.apache.org/docs/2.4/howto/ssi.html“ id=”tt-5” data-bs-html=”true” data-bs-custom-class=”custom-tooltip” data-bs-toggle=”tooltip” data-bs-placement=”bottom” title=”Tutoriel Apache httpd : Introduction aux “Inclusions Côté Serveur” (Server Side Includes - SSI) - Serveur HTTP Apache Version 2.4”>Inclus côté serveur (SSI)

API de modèle

balise ssi

Syntax:

{% ssi `/content_rooted/path/to/source_file` %}

filtre ssi

Syntax:

{{ content|ssi }}

Outils de paramétrage des liens permanents

Durée du document

Le système de construction d’Orion a intégré la prise en charge de ce que nous appelons Curation de document, qui est le processus de recontextualisation et de réorganisation de votre contenu en fonction de la façon dont vous définissez le Catégories et Statut en-têtes dans vos fichiers source Markdown. Ces fonctionnalités sont désactivées par défaut, mais peuvent être activées en définissant une category_root (pour la prise en charge des catégories) ou archive_root (pour la prise en charge de l’archivage) dans l’argument hashref associé au @path : :modèles entrée.

Catégories
Pages archivées

Sur notre site, nous archivons de manière agressive les essais périmés afin de réduire le temps de construction des nouveaux essais, tout en ne détruisant pas les permaliens vers les documents archivés. Le graphique de dépendance par rapport à /archives/ Le répertoire (pour notre site) est raisonnablement autonome selon les règles suivantes :

Lede

Commentaires HTML intégrés dans les limites de la prose Markdown du contenu lede. Nous utilisons {# lede #} à cette fin.

Le traitement des ledes est effectué avec lede Filtre de modèle. Il est utile de combiner cela avec le ssi filtre permettant d’indexer un fichier de catégorie comportant plusieurs pages de catégorie.


Conclusions

Il y a des structures de données et des relations intéressantes à découvrir quand il s’agit du graphique de dépendance d’un site Web du point de vue de la performance de construction, ce qui est un domaine d’intérêt beaucoup plus récent que la littérature de recherche explorant les structures de données et les problèmes associés entourant la topologie des liens.1,2.

Les builds incrémentiels conventionnels pour les projets de développement de logiciels purs sont toujours un sujet brûlant. La recherche couverte dans 3,4 a été publié en octobre 2022, environ un mois avant que cet essai ne soit complet. Le pluton5 Le système de build possède des fonctionnalités assez similaires aux nôtres (le build lui-même peut régénérer et reconstruire dynamiquement les dépendances).

La bonne nouvelle est que nous vous avons couvert comme notre client. Nous vous tiendrons au courant des meilleures pratiques et de l’état de l’art dans cet espace, de sorte que vous bénéficierez de nos leçons apprises au cours de la dernière décennie et jusqu’à demain.


notes de bas de page

  1. Identification des clusters dans le graphique Web en fonction de la topologie des liens Septième Symposium international sur l’ingénierie et les applications des bases de données, 2003. Procédure.

  2. Inférer des communautés Web à partir de la topologie des liens Neuvième conférence ACM sur l’hypertexte et l’hypermédia : liens, objets, temps et espace — structure dans les systèmes hypermédias : liens, objets, temps et espace — La structure dans les hypermédias. 1998.

  3. Sur les avantages et les limites des configurations logicielles de construction incrémentielle : une étude exploratoire ICSE ‘22 : Actes de la 44e Conférence internationale sur le génie logiciel, mai 2022

  4. Vers la création incrémentielle de configurations logicielles ICSE-NIER ‘22 : Actes de la 44e Conférence internationale ACM/IEEE sur le génie logiciel : nouvelles idées et résultats émergents, mai 2022

  5. Un système de construction incrémentielle sain et optimal avec des dépendances dynamiques OOPSLA 2015 : Actes de la Conférence internationale ACM SIGPLAN 2015 sur la programmation orientée objet, les systèmes, les langues et les applications Octobre 2015