Comment gérer la versioning avec Oracle Apex
Oracle Apex est grande. Le plus gros problème que j'ai avec ça est de l'utiliser avec le contrôle du code source. Généralement après avoir fait un changement, l'application entière est exportée et le script SQL résultant vérifié dans le contrôle de code source.
le problème est que parce qu'il n'est pas clair ce que fait la plupart du script exporté, je dois traiter est essentiellement un fichier binaire. Cela signifie que les modifications de plusieurs branches de code source ne peuvent pas être fusionnées ensemble, ce qui limite sévèrement son utilité.
j'ai entendu parler de certaines personnes exportant chaque page et les mettant dans le contrôle de code source individuellement. Tout d'abord, cela sonne comme une douleur importante. Deuxièmement, Apex ne vous permet pas d'importer une page dans une application autre que celle à partir de laquelle elle a été exportée. Il est donc difficile d'avoir deux développeurs travaillant dans leur propre copie d'une application à la fois.
quelqu'un a-t-il trouvé un bon moyen de gérer Apex avec le contrôle du code source? Je suis l'aide de la Subversion, de la pensée, je doute, cela fait une différence.
4 réponses
j'ai traité de cette question. Un autre aspect du problème est que L'Apex est si étroitement lié à la base de données SQL sous-jacente que tout changement dans le SQL doit être reflété aussi bien (en d'autres termes, exporter chaque page a d'autres problèmes au-delà de la douleur énorme). En fait comme je sais que les composants partagés sont pas exportés lorsque vous exportez une page.
Nous avons traité cela en exportant toute la demande et en la vérifiant. Essentiellement, il n'y ce n'est pas une meilleure façon de gérer le versioning dans APEX. Je me souviens aussi avoir vu quelque chose sur le forum Oracle APEX qu'il y a une façon de diviser le fichier exporté dans les composants, mais je ne l'ai pas essayé.
application D'exportation Apex par défaut dans un fichier sql (exportation Apex). Mais aussi Apex a Apexexport Splitter, qui exportent l'application dans des parties séparées (css, template, etc.) La bonne manière, il est une validation de ces pièces dans le svn
1. Automatiser L'exportation D'APEX pour SVN
j'ai trouvé ce que je pense être une bonne solution pour cette question. L'idée principale est de transférer le développement sur les propres postes de travail des développeurs, et D'utiliser Subversion pour maintenir la synchronisation et fusionner toutes les différentes versions des applications APEX.
Cela fait ressembler le flux de contrôle source à ceci:
c'est-à-dire que chaque développeur a sa propre instance de la base de données Oracle, installée sur son propre poste de travail. Tant que tous les les IDs de l'espace de travail et de l'application sont synchronisés entre les postes de travail, fusionner des fichiers Apex dump est assez facile -- et avoir le contrôle des sources garantit qu'ils restent ainsi.
mon équipe utilise cette approche depuis près de deux ans maintenant avec d'excellents résultats.
sur la Base de cette expérience, j'ai écrit un petit article détailler l'ensemble de l'approche, car j'espère qu'elle sera utile à d'autres équipes.
pour ce que cela vaut, Nous fournissons un outil de développement d'applications pour les développeurs PL/SQL appelé Formspider qui est livré avec intégration intégrée avec Git. Divulgation complète, nous avons créé ce produit.