Développement WordPress d’entreprise

Les conditions qui changent la façon de le construire, plus que le budget. Les données qui comptent vivent dans un autre système, plusieurs groupes ont leur mot à dire, le contenu dépasse ce que quiconque peut gérer à la main, une interruption coûte cher et les mises en ligne exigent donc un processus, il y a des obligations d’accessibilité, de confidentialité ou de langue, et la plateforme doit survivre aux personnes qui l’ont définie.

Oui. À grande échelle, les échecs viennent de l’architecture plutôt que de WordPress lui-même. Un gros volume de contenu demande un modèle conçu pour lui et des requêtes écrites en conséquence, une intégration lourde demande de la mise en cache et une gestion des pannes, et un fort trafic demande de l’infrastructure et un plan de mise en cache. Nous avons construit et exploité des plateformes avec des intégrations de données externes, des modèles de contenu bilingues et des pipelines CI/CD.

Couramment. Dans la plupart de ces mandats, l’infrastructure, les exigences de sécurité et les systèmes auxquels nous nous relions appartiennent au service des TI du client. Nous travaillons selon ses contraintes, documentons ce que nous construisons pour son examen et attendons son approbation sur l’architecture et le processus de mise en ligne.

Souvent. Tout commence par une évaluation du code, de l’hébergement, des intégrations et du modèle de contenu, puis une réponse franche sur ce qui peut être maintenu tel quel et ce qui devrait être reconstruit. Vous avez cette réponse avant de vous engager dans un sens ou dans l’autre.

Oui. Architecture écrite, documentation des intégrations et des flux de données, information sur l’accessibilité et la sécurité, processus d’environnements et de mise en ligne, et modèle de soutien. Ce sont des livrables courants dans ce travail, et c’est ce que lit la personne qui fait l’examen.

Parfois. Il convient quand plusieurs sites doivent partager un code, un système de design et un processus de mise en ligne tout en gardant leurs contenus et leurs permissions séparés : divisions, régions, marques ou une paire bilingue. Il convient mal quand les sites ont besoin d’architectures différentes ou de leurs propres calendriers de mise en ligne. Nous prenons cette décision à l’étape de l’architecture, avant la construction.

Une plateforme d’entreprise entre dans sa plus longue phase au lancement. Nous restons l’équipe de développement pour les mises à jour, les correctifs de sécurité, la surveillance, les changements quand une API externe évolue, la performance à mesure que le contenu grossit, et les nouvelles fonctions. Si vous préférez ramener le travail à l’interne ou le confier à un autre fournisseur, la passation comprend la documentation, le dépôt et le dossier d’architecture.