Я работаю в государственном учреждении. Используемая здесь технология и методы разработки программного обеспечения довольно старомодны.
У них есть тонны дискового пространства, но нет подходящего места для хранения и поддержки приложений, которые используются для автоматизации большей части работы здесь.
Учреждение не позволит мне использовать программное обеспечение SCM, такое как GIT или SVN.
Каков наилучший подход для сохранения качества кода и возможности добавления новых функций в приложения в дальнейшем?
Как я могу помнить изменения, которые я внес в код, не нарушая его?
РЕДАКТИРОВАТЬ: я забыл упомянуть, у них есть сетевые диски для каждого из компьютеров и каким-то образом эти сетевые диски создают или сохраняют резервные копии в определенные периоды. Однако, если я не создаю свой собственный план, позволяющий сохранить свою работу и иметь возможность добавлять новые функции, не нарушая существующий код, нет большого преимущества перед решением SCM.
РЕДАКТИРОВАТЬ: так как многие люди предложили портативный Git, я должен добавить больше информации. Я попытался установить сервер Visual SVN, но это не удалось, потому что у меня нет прав администратора для установки. Я также пытался загрузить обычную оболочку Git, но брандмауэр или сетевые настройки не позволяли мне получить доступ к странице загрузки Git. Я даже пытался отправить портативный Git на мою электронную почту, которая является Gmail. Google обнаружил exe-файл в пакете, и это также не позволило мне загрузить переносную версию Git на мой рабочий компьютер. Еще одна вещь, которую я должен упомянуть, сетевая политика, применяемая к компьютерам через учреждение, не позволяет использовать устройства хранения USB. Вы можете использовать порты USB для зарядки смартфона или питания некоторых гаджетов, таких как маленькие колонки. Также, как упоминали некоторые люди, есть компьютеры, на которых даже Интернет запрещен.
источник
Ответы:
Вы можете свободно копировать роль, которую играет система управления исходным кодом, с помощью трех простых инструментов:
В основном ваш рабочий процесс становится:
Более монолитные системы управления источниками, такие как SVN или TFS, в основном делают это за кулисами.
Теперь реальность такова, что автобусная компания говорит своим водителям, что они не могут водить автобусы с аккумулятором, заставляя водителей толкать автобус вниз по склону, а затем нажимать сцепление, чтобы запустить автобус ... это ужасно и указывает, что нынешнее руководство ничего не знает о работе автобуса. Мои соболезнования.
Но, по крайней мере, вы можете начать автобус.
источник
Хотя консенсус определенно состоял бы в том, чтобы не работать на эту компанию, я не верю, что это действительно отвечает на ваш вопрос.
Вы не можете заменить SCM .
Вам могут не понадобиться обычные навороты полноценной системы. Например, компания может отклонить запрос на сервер, но разрешить использование локального SCM. Они могут не любить git, но разрешают subversion (или какую-либо другую систему управления версиями).
Есть, конечно, вопрос: чем пользуются ваши коллеги или какие-либо предыдущие работники? Если вы первый разработчик программного обеспечения, который у них есть, тогда вам пора очень сильно потратить ресурсы, которые вам нужны.
В конце концов, если ваша компания не уважает вашу роль и опыт и не предоставит вам необходимые инструменты, то вы столкнетесь с еще более серьезными (и более стрессовыми) проблемами, чем отсутствие контроля над источниками.
источник
По сути, существует проблема управления (ваша организация не понимает основ процесса разработки программного обеспечения , например, V-модель ), которая сводится к очевидной невозможности использования минимального рабочего процесса, методологии и инструментов нынешней эры. Это часто встречается (читайте о принципе Питера ).
Кстати, я полагаю, что недавний инцидент с железнодорожным транспортом SNCF в Париже в конце 2017 года имеет аналогичную причину (полное отсутствие культуры программного обеспечения на высоком уровне управления, следовательно, блокирование крупной парижской железнодорожной станции более чем на день; конечно, есть очень компетентные ИТ-команды в SNCF, но они не консультируются по основным решениям). Я могу назвать несколько европейских отраслей с полным отсутствием культуры программного обеспечения, и я уверен, что смогу найти подобные вещи даже в США.
Основная проблема: вы работаете в одиночку над своей базой кода или работаете с коллегами?
Если вы работаете в одиночку, вы можете использовать git локально на своем компьютере и
.git
периодически создавать резервные копии своего кода (и, возможно, даже своего хранилища) (в этом внешнем хранилище). Никогда не теряйте больше половины рабочего дня (поэтому делайте резервные копии своих данных периодически и надежно).(Я полагаю, что вы знаете, по крайней мере, и то,
git
и другоеsvn
и знаете о техническом превосходствеgit
; если вам даже не разрешено устанавливать какой-либо инструмент, например,git
на ваш рабочий компьютер, вам нужно серьезно поговорить с вашим боссом об этой проблеме: вам нужно возможность и авторизация для установки внешних инструментов с открытым исходным кодом (и это связано с вашей ответственностью выбирать, настраивать и устанавливать их разумно и тщательно, без известных уязвимостей )Если вы работаете с несколькими коллегами (я полагаю, что их меньше дюжины), вам необходимо убедить их всех использовать систему контроля версий, и вам, вероятно, нужно рассказать об этом своему непосредственному (и общему) руководителю. Он мог (возможно) решить (или просто неявно принять), что какой-то компьютер (возможно, даже какой-то старый рабочий стол, возможно, даже ваш собственный рабочий стол) используется в качестве git-сервера. Вам необходимо настроить этот сервер таким образом, чтобы резервное копирование git выполнялось по крайней мере каждый час; вы не можете позволить себе (и вам нужно поговорить с вашим боссом) потерять более часа работы вашей команды.
Кстати, я люблю Linux, и я бы порекомендовал установить Linux на машину, выступающую в роли
git
сервера; тогда установкаgit
и настройка периодических резервных копий (с некоторымиcrontab
заданиями) очень проста; обратите внимание, чтоgit
сервер может использовать Linux с Windows-клиентами, использующими его. Я бы даже предложил вам переключить вашу машину для разработки на Linux, если вы можете. Это "дешевле" и гораздо удобнее для разработчиковНо вам нужно использовать SCM. Вы можете задать своему боссу другой вопрос: должна ли ваша команда использовать существующий SCM или она должна заново изобрести колесо и создать свой собственный SCM? Боссы вообще против идеи изобретать велосипед. Если вам разрешено заново изобретать колесо, скажите своему боссу, что он работает полный рабочий день, по крайней мере, год (что, вероятно, заставит вашего босса плакать, а затем примет очевидный путь) и получайте удовольствие от создания собственного SCM. В этом маловероятном случае обязательно изучите существующие системы SCM и попросите сделать вашу систему SCM свободным программным инструментом (который будет использоваться и улучшаться другими командами).
Вы , возможно , потребуется подготовить ( в течение нескольких дней) с точной и конкретной аргументации для потребности ЗМУ : первый для ваших коллег, то для непосредственного босса. Не забудьте также предложить конкретные решения (например, запустить какой-нибудь git-сервер на каком-то настольном компьютере или какой-нибудь «старый» сервер и ежечасно выполнять его резервное копирование через
crontab
работу)Не устанавливайте какое-либо программное обеспечение (извне, даже с открытым исходным кодом) на свой рабочий компьютер без разрешения (в большинстве стран, особенно для чувствительной работы в области информационных технологий для штата, установка программного обеспечения без разрешения является юридически преступлением, и вы можете потерять свой работу или отправиться в тюрьму, если вы это сделаете .... так что убедитесь, что у вас есть на это разрешение, возможно, прикрывайте свою задницу, спрашивая разрешение в письменной форме или, по крайней мере, по электронной почте).
(либо вам нужно будет спрашивать в каждом конкретном случае, либо вам необходимо получить доверие от вашей организации, чтобы вам было разрешено установить любое законное программное обеспечение - в основном с открытым исходным кодом или бесплатное программное обеспечение - на ваш рабочий компьютер).
PS. Техническая сборка, настройка, установка, а затем использование
git
(из исходного кода бесплатного программного обеспечения) или большинства других бесплатных программ VCS на компьютере (даже без разрешения администратора) - это совсем другой вопрос (который нужно задать в другом месте). И это можно установить и использоватьgit
без какого-либо разрешения администратора, при условии, что у вас достаточно ресурсов (времени, места на диске, некоторого компилятора C и т. Д.) Для этого.Это решается с помощью какой - то конкретной конфигурации и компиляции вашего
git
илиsvn
от свободного программного обеспечения исходного кодаgit
или SubVersion -не просто двоичная пакет- (а также исходный код из зависимостей ); как технически это сделать - это другой вопрос (но такие технические вопросы должны быть в другом месте). Конечно, вы должны попросить разрешения (у вашего босса), чтобы скомпилировать исходный код,git
прежде чем делать это. Он расскажет вам или вы обсудите с ним практические детали (если он примет такое решение) в отношении переноса этого исходного кода извне на ваш рабочий компьютер.источник
Во-первых, я бы определил, на что конкретно возражает государственное агентство (предположительно, отдел информационных технологий). Если у них есть место для хранения, но нет возможности разместить виртуальные машины для серверов, проблема может заключаться в том, что ИТ-отдел отказывает серверу SVN или GIT, и это большая разница. Если проблема в стране происхождения - то есть мы не доверяем инструментам, созданным иностранными организациями, - это другая проблема.
Вы можете полностью запустить GIT в файловой системе, что я делал для детских проектов, прежде чем я готов что-либо с ними сделать. GIT также не требует прав администратора для установки.
Если вы абсолютно не можете использовать Git по какой-либо причине, у вас есть несколько вариантов:
patch
иdiff
были сделаны так давно (80-х). Это были передовые технологии, которые сделали возможным управление версиями.Как выглядит развитие эпохи 70-х? Это не красиво, но так мы начали. Приложения были намного меньше. По сути, у них было несколько общих вещей:
patch
иdiff
заменить команду.По сути, это подверженный ошибкам процесс с большим потенциалом для того, чтобы что-то пошло не так. Идея «ветвления» легко реализуема, но управлять ей - просто кошмар. Основная проблема заключается в том, что когда у вас слишком много копий исходного кода, трудно понять, какова правильная базовая линия для производства. Ради практичности вы должны стать однопоточными.
Это то, что вам нужно включить в свой анализ альтернатив.
источник
Учитывая ограничения, которые вы упоминаете в комментариях (например: не можете попасть на страницу загрузки Git, платформу Windows и использовать Visual Studio 2005), я вижу 2 варианта, оба из которых я использовал ранее в аналогичной ситуации:
источник
Вам разрешено использовать его по своему усмотрению?
Если это так, вы можете создать удаленный репозиторий файловой системы, который лучше, чем ничего. Недостатком является то, что продвижение становится медленным, пока проект растет, потому что
git
нужно искать весь репозиторий для поиска изменений ...git
также поставляется как портативное приложение, так что вы можете установить его по пути $ HOME или% USERPROFILE%.В заключение: я бы не позволил им запретить мне использовать SCM 1 . Я бы использовал это "в частном порядке". В конце концов никто не может сказать, был ли ваш код разработан с или без проверки где-то ...
1 ) когда я начал использовать
git
несколько лет назад, мой клиент предпочел другой SCM, который был довольно медленным и ненадежным (в конце концов, это своего рода NOGO для SCM (o;). Я использовалgit
«один на один» поверх другого SCM с «файловым» пультом на общем сетевом ресурсе и регистрируется в их SCM только после выпуска новой версии продукта.источник
Ваше окружение
Прежде всего, я не был бы таким пессимистичным, как показано во многих комментариях и ответах. Да, это «каменный век», но обстоятельства гораздо хуже. Если ваша общая рабочая среда (коллеги, местоположение, оплата, интересная работа по программированию и т. Д.) В порядке и на ваш вкус, то непременно придерживайтесь ее. Что касается ИТ, то оно и есть. Это происходит не только в государственных учреждениях, но также в банковском деле, страховании или там, где очень большое внимание уделяется безопасности, или в очень старых структурах.
Вставка USB-накопителя и запуск некоторого .exe оттуда будут немедленной причиной для завершения в других местах, поэтому я бы не советовал вам пытаться обойти что-либо.
Попробуй мерзавец еще раз
Теперь на ваше усмотрение. Я бы настоятельно рекомендовал Git вместо SVN для вас. В любом случае, если вы делаете проекты с одним человеком, то git - это просто локальный каталог
.git
внутри корня вашего приложения, и ничего больше.Не спрашивайте у своего начальника / ИТ-консультанта «SCM», а попросите их специально установить
git
на вашу машину, чтобы вы могли разрабатывать быстрее и с более высоким качеством. Дайте им понять, что вы не хотите передавать свой код куда-то еще, что вам не нужен где-то работающий сервер и что он не будет занимать значительное пространство или время обслуживания.Git увеличит скорость и качество для вас просто потому, что вы можете работать с большей уверенностью (потому что вы можете отменить любые сделанные вами изменения) и позволить вам работать над несколькими ветками одновременно. То есть, если вы работаете над большой задачей, и вам нужно что-то, что требует вашего немедленного внимания, вы можете просто переключиться на новую ветку, быстро исправить это и затем вернуться к долгосрочной задаче.
Делать это вручную
Если это просто невозможно, то, конечно, вы можете сделать ручное управление исходным кодом. Создайте «теги» вручную, скопировав свой код (возможно, создайте новый каталог с датой / временем и кратким описанием того, что изменилось). Вести журнал изменений с подробными списками не только ваших изменений, но и файлов, которые вы изменили, и, возможно, даже более подробной информации.
Создайте «ветки», снова скопировав вашу работу, и когда придет время объединиться, проявить творческий подход с помощью произвольных инструментов «diff» или «diff3» - я не знаю, есть ли у вас какие-либо доступные, вам придется выяснить.
Если все это стоит много времени, то внимательно посмотрите, стоит ли вам эмулировать SCM. Если вы обнаружите , что это стоит, то поговорите с вашим боссом снова. Покажите ему преимущества вашего руководства SCM (не только «У меня есть копия всей моей старой работы», но «когда произошла ошибка XYZ, я сразу же смог найти причину, 5 выпусков назад»). Затем скажите им, насколько быстрее это будет
git
.Очевидно, что если это сводит вас с ума, поиск работы всегда является вариантом.
источник
Я думаю, что многим здесь не хватает «государственного учреждения» в этом вопросе. Некоторые правительственные сети имеют очень строгие правила в отношении программного обеспечения, разрешенного для них, и нарушение этих правил является уголовно наказуемым преступлением, возможно, даже уголовным. Я бы протолкнул его через руководство, чтобы посмотреть, сможете ли вы получить одобренное движение при установке программного обеспечения. Я бы не стал ковбойать и сам устанавливать вещи. Если вы работаете в Linux / UNIX, посмотрите, установлены ли RCS (команды ci / co) или SCCS (команда sccs). Это старые инструменты SCM, которые раньше были достаточно стандартными. Это не красиво, но лучше, чем то, что я собираюсь написать ниже. :)
Поскольку у вас «много» дискового пространства, создайте дерево исходных текстов. Каковы основы SCM в небольших масштабах? Будучи в состоянии проверить изменения, посмотреть, что изменилось, пометить вещи и вернуться к старым версиям, если это необходимо. На один уровень выше дерева исходного кода создайте Makefile или сценарии, в зависимости от того, что у вас есть, и выполните следующие действия (это Linux / UNIX, команды Windows могут отличаться)
make checkin - cp -a source-tree source-tree-date (по крайней мере, с точностью до минуты, если не секунды, например source-tree-20171205115433)
make status - diff -R source-tree source-tree-date | меньше (здесь будет немного логики, по умолчанию используется самая последняя резервная копия или приведен аргумент для сравнения с версией
make tag - ln -s source-tree-date release1.0 (сделать ссылку на определенную версию)
make revert - rm -r source-tree && cp -a source-tree-date исходное дерево
источник
Продай им это
Вы оставили этот комментарий :
Иди к своему начальнику и скажи что-нибудь в этом духе:
Резюме высокого уровня здесь заключается в том, что вам нужно изложить его так, чтобы они могли его понять и, вероятно, считают, что оно того стоит:
Ваши начальники не технические люди, и они не заботятся о технических проблемах. Но если вы можете сформулировать проблему с точки зрения денег и вещей, которые стоят денег, их уши могут немного оживиться.
источник
Итак, прочитав ваш вопрос и множество комментариев, я понял, что у вас есть следующие ограничения / сценарий:
Если вы не можете использовать Visual Source Safe (который имеет плагин для работы с VS 2005), то вы можете использовать другой подход.
Исходя из вышеперечисленных пунктов, я предлагаю вам организовать папки вашего проекта, такие как ниже:
Основные правила, которым нужно следовать здесь:
источник
У вас закончились технические решения. Остались только политические решения.
1) Объединить разработчиков. Если профсоюз уже существует, оспаривайте их положение как не совсем представляющего класс работника, который является разработчиком. Если формирование союза разработчиков не может получить поддержку половины разработчиков, GO. Вы плохо подойдете.
2) Газетная реклама. Если ваше правительство не гарантирует свободу слова как признанный вопрос права, это уволит вас.
источник
Git для Windows имеет «портативную» версию . Вы можете скопировать это на свой ПК или сохранить на карте памяти, без необходимости что-либо устанавливать. Если проблема заключается просто в установке, это будет обходной путь.
Обратите внимание, что если они категорически против SCM, вы можете задать точные вопросы о ISO-9001, DO-178B или других соответствующих стандартах разработки программного обеспечения.
источник
Просто запустите git над пустым каталогом, без какого-либо сервера. Неважно, что никто не использует контроль версий, потому что вы можете контролировать версию своего каталога. Git был разработан именно для этого мошеннического сценария внедрения SCM, и он работает хорошо.
Вы станете героем, когда второй человек начнет использовать его, даже если вам придется ждать, пока какой-нибудь динозавр пойдет в гору, чтобы он распространился. Сейчас некомпетентно управлять большими базами кода без SCM. На самом деле это все равно, что вести бизнес, ничего не проверяя.
источник
На самом деле есть три вещи, на которых вы хотели бы настаивать как профессионального разработчика: обзоры кода, история версий и отслеживание запросов на изменение.
Вы можете самостоятельно отслеживать запросы на изменение. Не так хорошо, как с правильными инструментами, но вы можете. Вторая часть - это обзоры кода. Для этого вам понадобится предыдущая копия вашего кода и инструмент сравнения. Когда вы думаете, что изменение готово, вы сами просматриваете его, тщательно сравнивая с предыдущей версией, а затем заменяете предыдущую версию новой.
Для контроля версий, если ваше рабочее место не позволяет найти какое-либо достойное решение, вам нужна коробка записываемых DVD-дисков. Каждый раз, когда у вас есть версия, которую вы хотите сохранить, чтобы иметь возможность вернуться к ней, вы создаете новый DVD.
(Очевидно, что все это не совет, который следует принимать, если вы не находитесь на действительно плохом рабочем месте, как, очевидно, ОП).
источник