Fondamentalement, il existe un problème de gestion (votre organisation ne comprend pas les bases du processus de développement logiciel , par exemple le modèle V ), qui se résume en une incapacité apparente à utiliser un flux de travail, une méthodologie et des outils minimaux. Ceci est courant (lisez à propos du principe de Peter ).
BTW, je suppose que le récent incident ferroviaire SNCF à Paris fin 2017 a une cause similaire (absence totale de culture logicielle à un niveau de gestion élevé, d'où le blocage d'une grande gare parisienne pendant plus d'une journée; bien sûr, il Les équipes informatiques de la SNCF, mais elles ne sont pas consultées sur les décisions majeures). Je peux nommer plusieurs industries européennes totalement dépourvues de culture du logiciel et je suis sûr de pouvoir trouver des choses similaires, même aux États-Unis.
Le problème principal est: travaillez-vous seul sur votre base de code ou travaillez-vous avec des collègues?
Si vous travaillez seul, vous pouvez utiliser git localement sur votre ordinateur et sauvegarder votre code (et probablement même votre .git
référentiel) périodiquement (sur cet espace de stockage externe). Assurez-vous de ne jamais perdre plus d'une demi-journée de travail (alors sauvegardez vos données de manière régulière et fiable).
(Je suppose que vous connaissez au moins les deux git
et svn
et que vous connaissez la supériorité technique de git
; si vous n'êtes même pas autorisé à installer un outil comme git
sur votre ordinateur de travail, vous devez avoir une conversation sérieuse avec votre patron à ce sujet: vous avez besoin la capacité et l'autorisation d'installer des outils open source externes (et cela va de pair avec votre responsabilité de choisir, configurer et installer ces outils judicieusement et avec soin , sans vulnérabilités connues )
Si vous travaillez avec plusieurs collègues (moins d'une douzaine, je suppose), vous devez les convaincre tous d' utiliser un système de contrôle de version, et vous devrez probablement en parler à votre supérieur immédiat (et commun). Il pourrait (probablement) décider (ou simplement accepter implicitement) qu'une machine (peut-être même un vieux bureau, peut-être même le vôtre) est utilisée comme serveur git. Vous devez absolument configurer ce serveur pour que le référentiel git soit sauvegardé au moins toutes les heures. vous ne pouvez pas vous permettre (et vous devez parler à votre patron) de perdre plus d'une heure de travail de votre équipe.
BTW, j'adore Linux, et je recommanderais d'installer Linux sur la machine faisant office de git
serveur; puis installer git
et configurer des sauvegardes périodiques (avec quelques crontab
travaux) est très facile; remarquez qu'un git
serveur peut exécuter Linux avec les clients Windows qui l'utilisent. Je vous suggérerais même de basculer votre machine de développement vers Linux si vous le pouvez. C'est "moins cher" et beaucoup plus convivial pour les développeurs
Mais vous devez utiliser un SCM. Vous pouvez poser à votre patron une question différente: votre équipe doit-elle utiliser un modèle de gestion de chaîne existant ou doit-elle réinventer la roue et créer votre propre système de gestion de chaîne? Les patrons sont généralement contre l’idée de réinventer la roue. Si vous êtes autorisé à réinventer la roue, dites à votre patron que c'est un emploi à plein temps pendant au moins un an (cela fera probablement pleurer votre patron, puis acceptera le moyen évident) et amusez-vous à créer votre propre SCM. Dans ce cas peu probable, assurez-vous d'étudier les systèmes SCM existants et demandez à ce que votre système soit un logiciel gratuit (à utiliser et à améliorer par d'autres équipes).
Vous devrez peut-être préparer (pendant plusieurs jours) une argumentation précise et spécifique sur la nécessité d’un SMC : d’abord pour vos collègues, puis pour votre supérieur hiérarchique. Assurez-vous également de suggérer des solutions concrètes (par exemple, exécuter un serveur git sur un ordinateur de bureau ou un "ancien" serveur, et le sauvegarder toutes les heures dans le cadre d'un crontab
travail).
N'installez aucun logiciel (de l'extérieur, même open-source) sur votre ordinateur de travail sans autorisation (dans la plupart des pays, en particulier pour les tâches informatiques sensibles effectuées par l'État, installer un logiciel sans autorisation est un crime, et vous risquez de perdre votre ordinateur. travail ou aller en prison si vous faites cela ... alors assurez-vous d’être autorisé à le faire, couvrez peut-être votre cul en demandant une permission par écrit, ou au moins par courrier électronique).
(Soit vous devez demander au cas par cas, soit vous devez obtenir la confiance de votre organisation pour pouvoir installer n'importe quel logiciel juridique - principalement des logiciels open source ou gratuits - sur votre ordinateur de travail).
PS Comment construire techniquement, configurer, installer puis utilisergit
(à partir de son code source de logiciel libre) - ou la plupart des autres logiciels libres VCS - sur une machine (même sans permission de l'administrateur) est une question très différente (à poser ailleurs). Et il est possible d'installer puis d'utiliser git
sans aucune permission d'administrateur, à condition de disposer de suffisamment de ressources (temps, espace disque, compilateur C, etc.) pour cela.
J'ai essayé d'installer le serveur Visual SVN, mais cela a échoué car je ne dispose pas de privilèges d'administrateur pour l'installation.
Ceci est résoluble par une configuration spécifique et la compilation de votre git
ou svn
du logiciel libre code source git
ou juste un SubVersion -non package- binaire (et aussi le code source de dépendances ); comment faire sur le plan technique qui est une autre question (mais ces questions techniques devraient aller à un autre endroit). Bien sûr, vous devriez demander la permission (à votre patron) de compiler le code source git
avant de le faire. Il vous indiquera, ou vous discuterez avec lui, des détails pratiques (s'il accepte une telle solution) concernant le transfert de ce code source de l'extérieur sur votre ordinateur de travail.