Un produit logiciel de Levelupsoft Inc.
SSemRepo est un dépôt que votre entreprise exploite elle-même. Dépôts, tickets, revue de code et wiki arrivent d’un seul tenant, et les développeurs gardent les commandes git qu’ils connaissent déjà.
Pourquoi l’auto-hébergement
Un dépôt externe démarre vite. En échange, la conception de votre produit et la trace de qui a changé quoi, et quand, s’accumulent sur une infrastructure qui n’est pas la vôtre.
Le code source, c’est tout ce que l’entreprise a construit. L’effacer n’est pas un geste que vous faites mais une demande que vous adressez, et la durée des sauvegardes est fixée par des conditions d’utilisation.
Sur un réseau interne fermé, en usine ou sur un site sans accès sortant, un simple clone ne passe pas. Certains endroits sont hors d’atteinte physiquement, pas seulement par règlement.
Quand la finance, la santé ou le secteur public demande où ce code est conservé, brandir les conditions d’un prestataire est la seule réponse disponible.
Produit
Quand l’endroit qui héberge le code et celui où l’on en discute sont séparés, on finit par acheter un second outil. SSemRepo livre les trois ensemble.
git clone et push passent en HTTPS tels quels. Fichiers, commits et différences se lisent dans le navigateur, et les dépôts Subversion repris se lisent sur les mêmes écrans.
Tickets, jalons, étiquettes et assignations ; demandes de fusion et revue de code ; forum et wiki. Tout tient dans un seul projet.
Groupes et droits, validation des inscriptions, notifications et modèles de courriel, logo du site et sauvegardes se modifient depuis l’administration. Rien de tout cela n’exige un redéploiement.
Fonctions
Clone et push en HTTPS, branches et étiquettes, liste des commits et différences, lecture des fichiers, édition web, forks.
Les révisions, fichiers et différences d’un dépôt svn repris se lisent sur les mêmes écrans que git. Inutile de jeter l’ancien.
Étiquettes, assignations et jalons, tickets parents et enfants, pièces jointes et commentaires, et une recherche qui ne rend que le visible.
Différences entre branches, commentaires de revue fichier par fichier, signalement des conflits, fusion et fermeture automatique.
Les annonces au forum, les règles et la conception au wiki — avec le même éditeur et les mêmes pièces jointes que les tickets.
Le produit parle coréen, anglais, japonais, chinois, allemand, russe, français, vietnamien, indonésien et espagnol.
Écrans
Le vrai coût d’un outil, c’est le temps passé à l’apprendre. La disposition suit ce que les développeurs connaissent déjà — les projets à gauche, le travail au centre, le code en haut.
À propos de cet écran
Ligne de commande
Ce qu’une personne enchaîne à la souris et ce qu’une machine répète ne sont pas le même travail. SSemRepo livre son propre outil en ligne de commande — à appeler depuis un script, à accrocher après une compilation, ou à confier à un agent de programmation.
Tickets, forum, wiki, demandes de fusion, jalons, groupes, jusqu’à l’administration du site. Les résultats reviennent en tableau pour les humains ou en JSON pour les machines.
Séparez les comptes en profils, puis liez un répertoire au compte qui doit y travailler. En dessous, c’est ce compte, sans rien demander.
Il se branche comme assistant d’identifiants git : le push cesse de réclamer un mot de passe. Les secrets enregistrés sont chiffrés pour cette machine ; copiés ailleurs, ils ne s’ouvrent pas.
Le mode d’emploi est fourni, prêt à être branché sur un outil d’IA. « Ouvre un ticket pour ce bogue » devient alors quelque chose qui s’exécute.
À propos de cette session
Architecture
Navigateurs et clients git arrivent à la même adresse. Le serveur web les passe à Tomcat ; l’historique va dans PostgreSQL et les fichiers des dépôts restent sur votre disque.
À propos de ce schéma
Migration
Les équipes qui ont déjà des années derrière elles sont plus nombreuses que celles qui démarrent. Les dépôts git et svn, les tickets et les pièces jointes de l’outil que vous utilisez aujourd’hui sont repris, avec la procédure et les outils qui vont avec.
Tickets, commentaires et historique sont lus dans la base de votre outil actuel et déplacés vers PostgreSQL. Les valeurs sont lues par le pilote et écrites telles quelles, jamais réécrites comme du texte.
Les dépôts git et svn ainsi que les fichiers téléversés sont copiés entiers, répertoire compris. Un dépôt reste un objet standard quel que soit l’outil d’origine : il n’y a rien à ajuster.
Utilisateurs, groupes et rôles suivent. Lorsque le schéma de mots de passe correspond, les anciens mots de passe fonctionnent encore et personne n’a à se réinscrire.
Avant d’éteindre l’ancien système, les mêmes données se comparent sur les deux écrans. On avance en gardant un chemin de retour.
L’ampleur et le calendrier d’une migration se déduisent du nombre de dépôts et de la taille du disque. Écrivez-nous : nous regarderons votre environnement avec vous.
Mise en place
Deux conteneurs — l’application et PostgreSQL. La seule décision est le disque où vivront les dépôts.
Créer les tables, charger les données initiales, puis créer le compte administrateur. Les commandes sont écrites dans le guide.
Pointer votre domaine et monter HTTPS. Comme le trafic git passe par là, il suffit de desserrer la limite de taille des requêtes.
Choisir le mode d’inscription, puis créer groupes et projets. En cas de migration, c’est ici que l’ancien matériel entre.
Technique
Un serveur Java ordinaire suffit. Votre équipe d’exploitation le démarre et le redémarre comme elle le fait déjà.
Le SQL s’écrit directement, sans couche de correspondance entre les deux. Une requête lente se trouve dans la requête.
Le premier écran a été allégé pour s’afficher vite, et même les polices sont servies depuis votre réseau.
Ils tournent contre un vrai serveur — créer un projet, y pousser, ouvrir une demande de fusion — et non contre des simulacres.
Dites-nous la taille de votre équipe et ce que vous utilisez aujourd’hui ; nous proposerons une configuration adaptée et vous aiderons pour l’essai et la migration.
Nous écrirehalo@levelupsoft.com+82 10-8472-4070
Levelupsoft Inc.