👨 В Хельсинки родился человек, изменивший мир дважды: создатель ядра Linux и системы Git.
🐧 Линус доказал, что открытый код (Open Source) способен победить корпорации: сегодня на Linux работает весь интернет, суперкомпьютеры и миллиарды Android-устройств.
📱 А написанный им «от скуки» Git стал стандартом современной разработки, без которого невозможно представить ни один серьезный IT-проект.
Полагаю, ты недавно узнал о существовании Школы 21 от Сбера и сейчас изучаешь все отзывы чтобы решить идти или не идти на интенсив. Один пишет, что интенсив это лучшее, что было в его жизни. Другой проклинает тот день, когда пошел учиться и теперь ненавидит Сбер, все банковские карточки разрежет и в Сбер никогда больше не пойдет. Ты уже в легкой панике, так как те немногие отзывы оставляют больше вопросов, чем ответов.
Что же делать?
Я тебя очень хорошо понимаю! В примерно такой же ситуации оказался я.
Казалось бы, уже несколько тысяч человек прошли интенсив, а отзывов ну очень мало. Надеюсь, этот пост о Школе 21 многое для тебя прояснит, и ты сможешь сделать свой выбор.
Начну с того, что сам я о Школе 21 узнал случайно из рекламной интеграции. Как правило все такие интеграции я проматываю, но вот именно в этот раз я посмотрел всю рекламу целиком. В ролике говорилось, что обучение бесплатное, что в школе нет лекций, нет преподавателей, нет жесткого графика. Любопытство сыграло свою роль, и я стал искать больше информации.
Интенсив (иногда еще называют «бассейн»), который будет длится 26 дней, является отборочным этапом перед основным обучением. По его итогам Школа будет принимать решение зачислять или нет на основу. Тут я буду говорить исключительно о моем опыте прохождения интенсива, не затрагивая тему обучения на основе. У меня нет опыта работы в IT, но я уже пару лет самостоятельно изучаю направление анализа данных. Узнав, что в моем городе нет кампуса, я подумал, что дальше нет смысла смотреть. Ведь, все-таки нужно выделить 26 дней, чтобы пройти интенсив (только очно!). А это значит, что необходимо будет почти на месяц оставить семью, которая не привыкла к тому, что меня нет дома более 3х дней.
Однако, кампус был в городе, расположенном буквально в 2х часах езды. И ближайший интенсив был в очень приемлемые для меня даты. Но я опять засомневался, так как обучение должно было идти на языке С, на котором я никогда в жизни не программировал. И первые же уроки по языку С на Stepik’е заставили меня очень сильно задуматься о целесообразности дальнейшего изучения.
Ты еще не подал документы, но уже на данном этапе у тебя много сомнений и вопросов.
И, самый главный вопрос «зачем мне идти на интенсив?»
В первые дни при общении с другими участниками интенсива самым популярными вопросом был «зачем ты пошел на интенсив?». На первый взгляд между этими двумя вопросами нет никакой разницы. Однако, на первый вопрос ты отвечаешь сам себе, а на второй ты отвечаешь кому-то другому, и формулировка твоего ответа уже может отличаться. А в разных формулировках ты можешь найти какое-нибудь противоречие и невольно задаться вопросом почему так получилось? Или собеседник тебе может задать простой вопрос, над которым ты даже не задумывался, и твоя мысль уже не кажется тебе такой идеальной.
Итак, прежде чем решить сформулируй для себя ответ на вопрос зачем тебе идти на интенсив?
Лично я для себя сформулировал его так. Я пойду на интенсив, потому что я...
Никогда сам бы не стал изучать язык С. В качестве второго языка думал изучать R или Java, но насчет С даже не задумывался. А почему бы и да! Вообще, если ты хочешь работать в сфере IT, то знание 2х и более языков программирования дает тебе +100 к привлекательности резюме и +1000 к багажу знаний.
Никогда бы сам не работал только в терминале с помощью командной строки. Графический интерфейс изобрели еще несколько десятилетий назад. Ну камон, какая еще командная строка? В качестве ремарки скажу, что после интенсива я теперь дома пользуюсь терминалом и командной строкой практически регулярно.
Хочу научиться работать с Git. Этот навык вообще не будет бесполезным, если ты хочешь развиваться в IT. О крутости Git я знал еще ранее, но после интенсива, если у тебя ранее был опыт программирования, ты уже элементарно не понимаешь, как ты раньше мог работать без Git.
Хочу познакомиться с единомышленниками, получить от них что-то и поделиться своим опытом.
Хочу себя проверить на выносливость. Интенсив длится 26 дней, без выходных! Да еще и экзамены каждую пятницу.
Хочу посмотреть как я буду работать в команде. В процессе прохождения интенсива у тебя будет три групповых проекта. Все группы формируются рандомно. У каждой группы свой тим‑лидер. Возможно, им будешь ты. Да‑да!
Если ты еще не подавал заявку на поступление, то ты еще не проходил проверочные тесты. Они, в целом, не сложные. Один на память, второй на логику. Но не нужно думать, что эти тесты ты пройдешь в любом случае. Большое заблуждение, что они призваны лишь отсеивать ботов. Обязательно выдели на тесты час чтобы тебя никто не отвлекал, будь бодр и спокоен! После успешного прохождения тестов тебя ждет онлайн встреча, где все расскажут и подробно ответят на все вопросы. Тебе останется только отправить оригиналы необходимых документов непосредственно в школу. И все! Тебе придет заветное письмо, что тебя ждут на первый день интенсива.
Поздравляю! Твое обучение уже началось.
Да, оно началось именно сейчас! Не нужно ждать дня начала интенсива, зачеркивая дни в календаре. Тут я немножко раскрою великую тайну и скажу, что Школа 21 очень сильно лукавит, когда говорит, что начать обучаться можно не имея никаких знаний. Формально это так и в моем потоке были люди, которые, по ощущениям, компьютером в обычной жизни пользуются не часто. Например, я объяснял одному пиру (участнику интенсива) сочетание клавиш ctrl+c ctrl+v, т.к. человек ранее копипаст всегда делал только с помощью правой кнопки мыши. Но было видно насколько тяжело этим людям дается изучение материала. После первой недели интенсива стало заметно что количество его участников уменьшилось.
В целом можно смело говорить, что чем ниже уровень твоих знаний, тем выше порог вхождения в темп обучающего процесса интенсива!
Я тебе очень сильно рекомендую еще до начала интенсива пройти краткий курс по программированию на С, курс до Git и курс по Bash. Об этом, кстати, будет написано в памятке от самой школы. Это в разы понизит порог вхождения в процесс. Скажу больше – ты будешь готов сдать первый экзамен еще даже не начав прохождение интенсива!
Уже на первой неделе интенсива нужно будет написать программу с использованием алгоритма рекурсии. Возможно, ты сейчас первый раз в жизни это слово услышал. В алгоритме ничего сложного нет, пишется в три строчки. Скорее тревогу вызывает странное слово «рекурсия».
Главное понять, что это и самому реализовать. К первой пятнице интенсива ты должен понимать как работают условные операторы, циклы и, особенно, вложенные циклы. Много задач с интенсива решаются с помощью вложенных циклов, а решение групповых проектов без их использования, пожалуй, невозможно.
Таких моментов будет много. Будь готов к тому, что каждый день ты для себя будешь открывать что-то новое. И это новое нужно понимать, усваивать и применять в процессе прохождения интенсива. И так все 26 дней.
Ну что готов? Тогда поехали дальше.
Ты сейчас задаешься вопросом о каком обучении может идти речь, если никто не будет обучать? Как писал выше в школе нет лекций и преподавателей. Однако, это не совсем так.
Главный принцип обучения в Школе 21 – метод peer-to-peer, по которой каждой учится у каждого. На первый взгляд и понятно, и не понятно одновременно.
Программа прохождения интенсива расписана на все 26 дней. В первый день одна тема, во второй другая и так далее. Сложность тем и задач по ней увеличивается с каждым днем. Ты можешь посмотреть какая именно тема будет в тот или иной день, но сами задачи откроются непосредственно в день по расписанию. На решение задач каждого дня дается 36 часов, на групповой проект 60 часов. Тебе дается только условие задачи и требования к итоговому результату. И все…
Что делать-то? Куда нажимать? Что вообще от меня хотят?
Примерно такие мысли у тебя будут в первый день. И опять паника и первые мысли, что пора валить пока не поздно. Но кто-то заметит, что на портале есть видео‑инструкции и поделиться этим со всеми. Кто-то заметит, что в файлах репозитория есть условие задачи, написанное на русском языке и поделиться этим со всеми. Кто-то даже знает как решать задачу, соберет желающих перед доской с маркером и расскажет свои мыли об этом, а кто‑то в процессе поделиться своим подходом к решению. В конце концов есть Google, YouTube, ChatпростигосподиGpt и прочие ресурсы. И в итоге большая часть потока задачу решает. У тебя есть трудности в решении задачи? Подойди к соседу, спроси. Есть вероятность, что он уже решил подобную задачу. Или же другой пир испытывает сложности с тем, что ты уже сделал или знаешь, как сделать. Подойди и подскажи ему. Таким образом, ты еще раз сам для себя закрепишь материал. Peer‑to‑peer работает!
И это я привел самый простой пример peer-to-peer. У меня сложилось впечатление, что если условным домохозяйкам, которые компьютер используют только для просмотра сериалов и поиска рецепта блюда на ужин, дать задание написать код для незатейливой консольной игры и закрыть в кластере с компьютерами с доступом в интернет, с помещениями для сна, с зоной для прогулок, со спортзалом с душем, предоставив им питание, воду, чай и прочие плюшки, то через месяц они напишут код и смогут объяснить каждую его строчку.
На моем потоке очень много пиров устраивали собственные лекции, поэтому лекций было много. Доходило даже до того, что в одно и то же время были две лекции в разных помещениях. И это не обязательно были лекции по тематике интенсива. Так пиры читали лекции про 3D‑моделирование, про информационную безопасность, про тимбилдинг, про онлайн продажи, про основы музыки, настольных игр, итд. Чего только не было! Школа никак не ограничивает тебя и как ты будешь саморазвиваться и реализовывать себя в дни интенсива. Более того, это даже поощряется путем присвоения очков трайба.
Да, кстати, турнир трайбов. В первый день весь поток рандомно будет поделен на три группы, именуемые трайбами (от англ. tribe – племя), с равным количеством человек. Каждый участник трайба будет зарабатывать очки, которые пойдут ему в личный зачет и в общий зачет трайба. У какого трайба в конце интенсива будет большее количество очков, тот и победит. Лучшие представители каждого трайба получат мерч. Зарабатывать очки можно осуществляя проверки заданий пиров, а также любой активностью, на которую придет как минимум 5 человек. Последнее как раз является стимулом для пиров организовывать мероприятия для неограниченного круга лиц. Турниром трайбов школа не дает пирам сидеть на ровном месте просто решая задачки. Если ты хорошо разбираешься в какой-либо теме, хотел ее донести до масс, но всегда боялся выступать перед аудиторией, смело организовывай лекцию!
Теперь немного о проверках заданий другими пирами. Перед началом интенсива, исходя из тех немногочисленных отзывов, у меня сложилось мнение, что задачи будут проверяться автоматически, как в Leetcode, а к пирам ты будешь обращаться с случае, если решение не проходит внутренние тесты системы. И общими усилиями вы найдете какое-нибудь решение. Однако, все оказалось не так.
После того как ты закончил выполнение задач проекта и загрузил их на репозиторий Git, по истечении дедлайна у тебя открывается возможность записаться на проверку к пиру. Чтобы записаться на проверку, другой пир должен открыть слот на проверку. Записаться к конкретному пиру нельзя, ты видишь только слоты. Если на это время открыты проверки у нескольких пиров, рандомно попадаешь к одному из них. Проверяющий пир также не знает заранее о том, кто к нему записался. Друг о друге вы узнаете лишь за 15 минут до начала проверки. Всего тебе необходимо будет провериться у трех пиров, после автоматическая система Verter сделает свою проверку и выдаст результат. Система очень коварная и местами не предсказуемая, некоторых выводила из себя.
Verter ты будешь буквально ненавидеть!
Чтобы стимулировать пиров на осуществление проверок, существует система заработка и траты peer review points или PRP. Что это такое? Изначально каждому пиру дается 5 PRP, которые он может потратить для проверки своих проектов. Проверка у одного пира стоит 1 PRP. У тебя 1 PRP списывается, проверяющий тебя пир получает твой 1 PRP. Так как необходимо осуществить 3 проверки, то, чтобы сдать весь проект, ты потратишь суммарно 3 PRP. Если ты не будешь сам осуществлять проверки заданий других пиров, то в какой-то момент у тебя не будет PRP для проверки собственных проектов. Поэтому, хочешь ты этого или нет, но проверять проекты других пиров тебе придется.
Однако у такой экономики есть свои недостатки, с которым многим из моего потока пришлось столкнуться. Во-первых, были люди, которые только проверяли других пиров, а сами свои проекты не сдавали на проверку, соответственно, лишали возможности другим пирам заработать PRP. В результате большое количество PRP были просто вне оборота и даже частично сгорали, т.к. один пир мог заработать максимум 15 PRP. Во-вторых, не справедливое распределение PRP при проверке группового проекта. Групповой проект проходит 2 стадии проверки: сначала у пира, затем у студента с основного потока обучения. Чтобы пройти проверку у пира каждый из группы тратит 1 PRP, всего с группы получается 3 PRP. Но проверяющий пир получает всего лишь 1 PRP, а значит 2 PRP просто сгорают. Таким образом только у одной группы после всех проверок проекта из микроэкономической системы сгорает 2 PRP. А групп несколько десятков.
С каждым днем задачи усложнялись, количество сдающих на проверку пиров уменьшалось, а количество желающих проверить, наоборот, увеличивалось. На третьей неделе интенсива на потоке случился буквально экономический кризис! Некоторые пиры ходили от стола к столу с вопросом есть ли что проверить, так как у самих не было PRP для проверок собственных проектов. В итоге случилась «забастовка»! Стихийная, но очень добрая и веселая. Вопрос был решен, но недовольство несовершенной экономике высказывали постоянно.
В проверке проектов также нет ничего сложно и страшного. У проверяющего есть чек-лист, по которому он сверяет выполнение задания и пятибалльная система оценки. Если что-то непонятно проверяемый пир с удовольствием (ну почти всегда) расскажет и покажет. Во время таких проверок ты общаешься с другими пирами, смотришь их решения, берешь для себя какие-то идеи, приемы. Сам что-то показываешь и объясняешь. В общем, интересный процесс, если не подходить к нему формально.
Кодить на время интенсивна нужно на языке С. Не С#, не C++. Именно С. Поскольку я ранее программировал на питоне, программирование на С первое время вызывало боли и страдания. Вот без преувеличения! Ощущения примерно такие же, как если бы ты всю жизнь ездил на BMW с автоматической коробкой передач и всеми удобствами типа ABS, климат‑контроль и прочими радостями для водителя, а тут тебя сажают за Ладу c убитой ручной коробкой, сломанной подвеской, да которая еще и заводится не с первого раза. Каждый раз, пытаясь доехать из пункта А в пункт Б, ты будешь со слезами вспоминать как тебе было хорошо на твоей BMW.
В этом и заключается одна из главных особенность языка С. Ты невольно начинаешь разбираться как же оно работает и как сделать так, чтобы оно работало лучше. Когда ты на BMW тебя не заботит что творится у нее под капотом. Едет себе и едет. А на Ладе уже приходится все разбирать, самому ремонтировать, изучать принципы работы. Так и на интенсиве помимо синтаксиса языка учишь как устроено взаимодействие кода с железом компьютера, учишься управлять памятью, не допуская ее утечек.
Если ты не сдался и все же прошел все 26 дней интенсива, то можешь себя поздравить! Ты – красавчик! Ты сам это поймешь после выхода с последнего экзамена. Момента, когда интенсив официально заканчивается. И не важно какие у тебя были успехи, сколько проектов у тебя отмечены зеленым цветом. Важно то, что ты прошел этот путь. Пусть даже по итогу интенсива школой будет принято решение тебя не брать на основу, ты все равно получишь огромный опыт soft skills.
Но главный секрет школы, а именно критерии отбора на основное обучение, так и останется секретом. Школа никогда не раскроет критерии отбора обычному студенту. Поговаривают, что их больше сотни. На эту тему очень много слухов и всяких теорий, доходящих до абсурда. Можно даже устраивать хит-парады наиболее невероятных предположений какие именно критерии применяются. Самой нелепой версией для меня была конспирологическая теория о том, что в кампусе расставлены скрытые камеры и микрофоны, которые записывают разговоры пиров. А потом эти разговоры анализируются администрацией при принятии решения. Поэтому всегда в общении между собой хвалите администрацию и школу!) Шутка, конечно, но кто его знает.
Глядя на результаты отбора из моего потока, вопросов по критериям отбора становится еще больше. Одним из объективных показателей является прогресс обучения, который выражен в процентном соотношении. Изначально все пиры находятся на нулевом уровне (lvl 0), прогресс растет с успеваемостью. Большинство так и остается на нулевом уровне, со средним прогрессом 50-60 %, лишь единицы доходят до первого уровня (lvl 1). И если у одного пира процентов больше, чем у другого, это совершенно не значит, что шансов у первого больше. Ровно такая же логика и с количеством успешно сданных проектов. Успеваемость безусловно учитывается, но зависимость не прямолинейная. Даже достижение 1 lvl не является гарантией того, что тебя возьмут на основу. Поэтому не нужно равняться на других и стремиться за ними угнаться. Это лишь навредит твоему ментальному здоровью. Единственный с кем себя стоит сравнивать так это с самим собой!
Но я для себя выявил некоторые критерии, которые, на мой взгляд, существенно влияют на итоговое решение.
Во-первых, все тот же peer-to-peer. О том, что это один из основополагающих принципов школы тебе будут говорить постоянно. Буквально эта фраза будет очень часто произноситься при любом удобном случае. Ну так прислушайся к ней и действуй! Активно проверяй проекты других пиров, сам сдавай свои проекты, даже если ты сделал всего одну задачу. Организовывай лекции, встречи, сабантуи. Не сиди на месте! Я абсолютно уверен, что даже если ты сдашь все экзамены на 100% результат, но при этом не будешь сдавать свои проекты на проверку, у тебя будут минимальные шансы на попадание в основу. По большей части негативные отзывы о школе написаны именно такими людьми, которые не поняли как им таким умным отказали в дальнейшем обучении. На основе также действует принцип peer-to-peer. Если ты им пренебрегаешь, то зачем тогда ты будешь нужен школе?
Во-вторых, посещаемость кампуса. Обрати внимание на этот показатель в своем профиле. Твой показатель среднего нахождения в кампусе должен быть минимум 5 часов в день. Тут очень простая математика. Как писал выше каждый твой проект должен пройти 3 проверки у пиров. По умолчанию на одну проверку в системе выделяется минимум полчаса, значит 1,5 часа в день уйдет на проверки своих проектов. Так же на проверку проектов других пиров дается минимум полчаса на каждую. Значит на проверку трех пиров уйдет 1,5 часа. Уже как минимум 3 часа в день уходит на проверки, а еще же свои проекты писать надо, учиться, слушать лекции и так далее. Поэтому, если ты работаешь и планируешь приходить в кампус в вечернее время на несколько часов, возможно, это не оптимальный вариант. Лучше возьми отпуск. Кстати, спать в кампусе нельзя.
В-третьих, положение в турнире трайбов. У первых пяти пиров по итогам турнира трайбов самые высокие шансы на попадание в основу. Если по итогам 1,5 – 2 недель ты увидишь, что в своем трайбе ты по рейтингу во второй половине списка, срочно принимай меры! Какие – читай выше.
В заключение скажу, что это был очень интересный и позитивный опыт. У меня были скептические настроения перед началом, но в последний день было очень грустно расставаться со школой и большим количеством новых знакомых. Если ты когда-либо ездил в летний лагерь, то понимаешь эти ощущения, когда тебе грустно в день приезда и в день отъезда. И мне было очень приятно вновь пережить эти ощущения спустя много лет, прошедших с детства.
Мы действительно все очень сильно сдружились как между собой, так и с волонтерами и администрацией школы. Сейчас периодически встречаемся и активно поддерживаем отношения.
Поверь, каким бы интровертом ты ни был, ты обязательно найдешь родственную душу или даже целую приятную для тебя компанию. Состав интенсива очень разнообразен во всех отношениях. Тут нет ограничений по возрасту (не считая минимального возраста в 18 лет), по социальному статусу, по багажу знаний и так далее. Пиром может быть хоть студент, хоть директор крупной фирмы, успешный бизнес-коуч, многодетная мать, полковник в отставке, слесарь на заводе. Перечислять можно бесконечно. На время интенсива вы становитесь одним большим коллективом, решающим общую задачу. И на сколько дружным и сплоченным будет ваш коллектив решать только вам.
Вы сталкивались с проблемой, что рабочий проект клонируется 10 минут?
А когда начинаешь разбираться: почему так? То оказывается, что внутри десятки непережатых картинок для фронта, которые еще и менялись регулярно (а значит, оставили след в истории git навсегда).
Данная проблема влияет не только на локальное использование, ведь мы на самом деле довольно редко делаем git clone с нуля, но и самое главное – на скорость всех наших сборок (если мы не используем `fetch-depth: 1` или аналог, а использовать их надо).
Для лиги лени: продукт есть, но есть куда расти. Некоторые вещи вызывают недоумение. Медведь годный.
Годный медведь
Учебник по интиму часть 1. Введение Часть 2. Стоит только нам взять телескоп и посмотреть вооружённым глазом Часть 3. Давайте пробовать поставить Часть 4. Немного душноты Часть 5. Gitflic api Заключение
Учебник по интиму часть 1. Введение
Пришли ко мне в личку, в запрещенной в РФ сети, бывшие коллеги с вопросом, а знаю ли я, а могу ли я посмотреть, и им показать, что такое гитфлик (GitFlic). Я про такое первый раз слышу, потому что за импортозамещением в ИТ в РФ не слежу. Нет смысла следить за переименованиями, типа Debian 10-11-12 – Astra, Samba – ALD, Панголин – PostgreSQL, и так далее.
Тут вот, свой продукт.
Погуглил. На сайте новостей Минцифры – две рекламные статьи, обе от 2021 года: Первая - GitFlic. Российский GitHub и вторая, ответ на нее, «GitFlic: нас обвинили в «распиле». На этом все. Остальное – 3 рекламные статьи, и два треда на лоре «как это работает вообще без техподдержки». И, внезапно, статья от 1с – Инфостарт, Автоматизация процесса разработки с помощью сервиса GitFlic. Пока дописывал статью, нашлась еще одна минцифровая статья «Cборка Java-проектов в GitFlic Kubernetes-агентом»
GitFlic не является форком какого-либо решения. Он написан с нуля и создан без иностранного участия, поэтому не зависит от внешних факторов и сторонних разработок.
В отличие от GitLab и GitHub, которые разработаны на Ruby и Ruby on Rails, GitFlic написан на Java. Это обеспечивает стабильность и производительность даже для крупных проектов.
Это Java то про производительность? Ну ладно
В 2023 году продукт был куплен Астрой
ГК «Астра» продолжает реализацию стартовавшей в 2020 году M&A-стратегии и объявляет о вхождении в контур группы ООО «РеСолют», разработчика GitFlic —сервиса для работы с исходным кодом и его хранения. Сделка проводится в два неразрывных этапа, по завершении которых в конце текущего года ГК «Астра» получит мажоритарную долю 51%. Оставшаяся часть акций будет по-прежнему принадлежать основателям компании: Алексею Синицину, Максиму Козлову, Тимуру Миронову, Денису Рамазанову и Константину Леоновичу. Стратегические договоренности компаний предполагают, что в дальнейшем ГК «Астра» сможет еще увеличить свою долю в разработчике.
Ну был и был, мало ли чего скупила Астра.
Часть 2. Стоит только нам взять телескоп и посмотреть вооружённым глазом
Продукт позиционируется как комбайн с вертикальным взлетом – тут и хранение кода (вместо GitLab Self-Managed), и хранение итогов сборок вместо Maven (Реестр пакетов Maven), Nexus, и так далее. С релиза 3 объявили что «Релиз 3.0.0 отличается удобным интерфейсом, развитой функциональностью и способен стать полноценной заменой зарубежных продуктов GitHub, GitLab, Nexus, Artifactory, Jenkins и т.д.»
Пишут, что теперь работает и с OneScript (это для 1с). Обещают замену не только хранению кода, но и CI\CD, почти как в GitLab Runner или в GitHub Actions. В версии 4.6 пообещали что уже добавили: Проксирование реестра пакетов Deb Проксирование реестра пакетов Helm Прочее - 4.6.0 Что нового Обещают, что к проекту подключилось 100500000000 пользователей, но на этом все. Просто все. Зато в 4.4 отобрали манифесты:
Из стандартных пакетов убраны манифесты для k8s. На смену им пришли Helm Charts
При этом примеров «как это работает» и рассказов, кроме «мы внедрили, интерфейс красивый» - нет. Реклама есть. Сообщества нет. Примеров нет. Чат в телеграмме есть.
У продукта два исполнения – облачное и self-hosted. Облачное ни коллегам, ни мне не интересно, а на self-hosted можно и посмотреть.
Дальше я буду попутно сравнивать с GitLab Community Edition. Не потому, что он какой-то супер, а потому что я его видел, и с ним время от времени сталкиваюсь. У GitFlic Self-Hosted возможностей вроде сильно побольше, но посмотрим.
Все. На самом деле нет, если посмотреть Gitlab CE Self-compiled installation, то там английским по белому написано: In GitLab 18.0 and later, PostgreSQL 16 or later is required.
GitFlic Self-Hosted. Требует Redis и PostgreSQL. Зачем им редис – не понимаю. Но, GitLab Community Edition включает NGINX, Postgres, Redis, так что, есть и есть, как и у GitLab CE
Сама web страница загрузки (их репо) малость странное. Сверху указывается «N дней назад», и только внизу указано 2025-11-06, причем зачем-то этот фрагмент как-бы-защищен (нет) от выделения и копирования.
В реестре контейнеров последний бесплатный дистрибутив - gitflic-server-ce Бесплатный дистрибутив GitFlic Версия latest Опубликован 26 марта 2025 г.
Скачан целых 5 (пять) раз.
Дистрибутивы: Gitlab CE в варианте gitlab-ce_18.3.6-ce.0_arm64.deb. GitLab Community Edition (including NGINX, Postgres, Redis) Package Size 1.31 GB Installed Size 3.55 GB MD5 7244b435f26e74991f02a6525c4d3d26 SHA1 11c154d0bb4df6e9be39af864185d0cdfac7ea9e SHA256 6b3e1ae33d8dd89c7344338fc51f98e39d992b2c87e6b6e0167d91b496390868 SHA512 479be83c2f8eb0247637097e5b1863f2eafe1787ed9e9b843e470eed343e8328799187b5153d723b6c756405e64005fd9b4faa59da471ded412a259643e254cf
Дистрибутивы:gitflic .. все сложно. По ссылке – лежит описание по 4.6.0 По другой ссылке Лежит короткий readme, ссылка на сам файл gitflic-server_onpremise_4.6.0.zip, и ничего кроме. MD5 ? SHA? Не завезли. Ссылку для wget ? Не завезли.
Файл gitflic-server_onpremise_4.6.0.zip размером 780590717 байт. MD5 25C91261305A3EDA778684363D1D9D4F SHA256 67DE3A8EFAD516DB39196E9DA6726E4A5287D51F60950951C62106C22CC4301D
На момент начала написания статьи обновление вышло буквально вчера (статья писалась почти 2 недели, работы привалило, откуда не ждали). Буду смотреть сразу свежее.
Часть следующая, давайте пробовать офлайн
У дебиан опять поменялась страница загрузки, так что, например, отсюда https://cdimage.debian.org/debian-cd/current/amd64/iso-dvd/ берем debian-13.2.0-amd64-DVD-1.iso Тестовая VM, 2 vCPU, 4 Гб памяти, 45 Гб жесткий диск, Debian 13. Next-next-без графики-готово-забираем обновления – готово. Правим /etc/network/interfaces и /etc/apt/sources.list Заодно правим /etc/sysctl.conf от ipv6 и /etc/resolv.conf для DNS Убеждаемся в том, что по неведомым причинам /usr/sbin/ так и не прописан в путях по умолчанию, делаем ребут. /usr/sbin/shutdown
Смотрим – получилось меньше 5 Гб всей виртуальной машины. Заливаем туда gitflic-server_onpremise_4.6.0.zip, отключаем сеть на уровне гипервизора и идем читать инструкцию
В инструкции куча слов про создание папок и установку из zip, но ни слова про то, что jar файлы по умолчанию запускать нечем. Между тем, ПО идет как jar - gitflic.jar, размером 444275979, MD5 7ADC17898B22007B71C8C3D305777B42 SHA256 19468BAE05E83ADB6F56792C7BB6C946CE40CFD2F35F47B72BF77CAF879DF7B4
Поэтому, кроме упомянутого в руководстве apt install unzip , нужно сделать и apt install default-jdk. Еще в инструкции по установке везде стоит sudo, его тоже нет в debian по умолчанию. Хотите – ставьте. Дальше хотелось бы делать по инструкции, но так не выйдет. Потому что инструкцию надо было читать с самого начала, раздела «Предварительные условия», а не как я, сразу перейдя к установке приложения.
В предварительных условиях указано: OpenJDK 11 default-jdk на момент написания статьи - openjdk 21.0.9 2025-10-21, OpenJDK Runtime Environment (build 21.0.9+10-Debian-1deb13u1)
Затем, везде в инструкции стоит использование sudo. Его по умолчанию нет в Debian, поэтому apt install sudo
В инструкции указан PostgreSQL 11. Последняя версия, 11.22, вышла два года назад, 2023-11-09. Актуальная версия – 18.1, или хотя бы 17.7. А тут 11.
и дальше пойдем по инструкции из раздела Астры для PostgreSQL 11. Файла мандатного доступа etc/parsec/mswitch.conf у меня нет, и хорошо. В инструкции в пути мелкая опечатка, и в части установки расширений забыли написать \q дальше ставим Redis, ну или keyDB. Я поставил Redis - apt install redis, redis-cli ping отработал.
Остается сразу перевесить порт сервера с 22 на, скажем, 1122. Найду конфиг find / -name "sshd_config" , и поправлю. Потом ребут, и
Перейду к самой установке по инструкции mkdir /tmp/gitflic unzip gitflic_*.zip -d /tmp/gitflic – эта команда не сработает с ошибкой unzip: cannot find or open gitflic_*.zip, gitflic_*.zip.zip or gitflic_*.zip.ZIP.
for d in cicd repo img releases registry; do sudo mkdir -p "/var/gitflic/$d"; done; эта команда .. ну, я от рута делал, так что на sudo ругнется. sudo mkdir -p /opt/gitflic/bin sudo mkdir -p /etc/gitflic sudo mkdir -p /var/log/gitflic sudo cp gitflic.jar /opt/gitflic/bin sudo cp application.properties /etc/gitflic/application.properties sudo mkdir -p /opt/gitflic/cert sudo ssh-keygen -t ed25519 -N "" -q -f /opt/gitflic/cert/key.pem
И так далее. Шаг 13, конечно, тоже не сработает – нужно не useradd, а /usr/sbin/useradd --no-create-home --system --shell /sbin/nologin gitflic
Дальше в инструкции идет раздел «Конфигурация SSH порта». На .. то есть – зачем? Раздел «Конфигурация SSH порта» ссылается на следующий раздел, «Конфигурация и запуск». Это многое объясняет. Если же читать инструкцию с начала, а не с середины, то в разделе «Предварительные условия» написано – зачем:
Для того, чтобы было возможным использовать remote-url вида git@gitflic.ru:gitflic/gitflic.git, необходимо освободить стандартный 22 порт ssh сервера!
Раздел написан корректно, но можно чуть-чуть улучшить. Например, переписав весь список главы «установка под Астру» в раздел «просто установка». Но, можно и не переписывать, продукт куплен Астрой.
Все бы хорошо, но нельзя просто так и сделать только по инструкции. Не работает. Например, сделав systemctl status gitflic-server.service видно, что сервис есть, а веб консоли – нет. Почему? Потому что надо смотреть инструкцию лучше, сервис по умолчанию стартует как [::ffff:127.0.0.1]:8080
В инструкции написано:
После запуска перейдите по адресу, указанному при конфигурировании и проверьте работоспособность сервиса
Но в инструкции нет пункта «адрес конфигурации». Точнее, в самом начале инструкции указано: Перед конфигурацией приложения, ознакомьтесь с назначением параметров на странице Конфигурация application.properties
По пункту 9 инструкции по установке понятно, что параметры лежат в /etc/gitflic/application.properties, и внутри там написано # Дефолтное значение адреса localhost server.address=127.0.0.1 gitflic.base.url=http://localhost:8080 . Заодно и логи указано где хранить, logging.file.name=/var/log/gitflic/server.log
Ну, окей, все понятно, слушаем на локалхосте. Ничего такого. Там же указано: # При необходимости также можно указать порт, на котором будет запущен SSH сервер для работы # SSH транспорта git. Дефолтное значение порта 22 ssh.server.port=2255
Ничего не понятно, но очень интересно.
Ну да ничего. Правим в конфиге IP и делаем systemctl restart gitflic-server.service. Перезапускается пару минут (в ограниченной по ресурсам виртуалке), и появляется WEB консоль. Медведь хороший, мне нравится! Настолько хороший, что я выкинул из черновика картинки Kadabrus. Остается зайти: Стандартный пользователь и пароль Почта - adminuser@admin.local Пароль - qwerty123
Зашло. Работает. И даже работает после перезагрузки.
Итого по установке Медведь выбран удачно. Инструкция достаточна для установки. Есть мелкие недоделки, типа пропущенного в одном месте слеша, или \q для выхода из psql, но ничего критичного. PostgreSQL 11 надо менять на 16, 17 или лучше сразу 18. 11 – устарел. JDK тоже указан старый. В инструкции по LDAP авторизации сделано что-то не очевидное, но сейчас с этим разбираться лень
Часть 4. Немного душноты
С чем у коллег проблемы? Проблемы с тем, что они не разработчики, и им Git не нужен. Зато нужно брать секреты из Vault, и забирать к себе готовые плейбуки, ямл, открытые ключи, скрипты и так далее. И, кстати, контейнеры. Что умеет забирать файлы из онлайна? Если говорить про Linux, то это curl, wget, docker - docker push, далее со всеми остановками вроде Automate Ansible With GitLab и Build enterprise-grade IaC pipelines with GitLab DevSecOps. Если говорить про Windows, то есть Desired State Configuration, но иногда людям хочется интима и единообразия, так что мы получаем invoke-webrequest и Invoke-RestMethod. И то и другое относится к (кажется) System.Net.Sockets, но про это не будем. В Windows есть и wget, но это оболочка для invoke-webrequest, и есть два curl: один как командлет, и отдельный curl как честный curl.exe. Вот с этим всем и надо попробовать, как чего работает.
Начало простое: Отправка любого REST-API метода требует авторизации. Для этого необходимо создать токен доступа и указать его в заголовке запроса в следующей форме .. Создам проект MyNewproject01, в нем ветку master, в нем файл myfile01 с содержанием content01.
Для создания токена доступа через интерфейс необходимо: Перейти в профиль пользователя Перейти в раздел API токены Нажать кнопку Создать
Сказать что инструкция «не очевидная» - это ничего не сказать. Профиль пользователя виден и в левом меню, и в правом верхнем. И токены API генерируются в правом верхнем меню
Вот сюда не надо!
СЮДА НЕ НАДО
Надо вот сюда!
Надо вот сюда!
Токены то есть, но токена «чтобы только читал» там нет. В Gitlab сделано понятно, надо дать read_repository: Grants read-only access to repositories on private projects using Git-over-HTTP or the Repository Files API. read_user (Grants read-only access to your profile through the /user API endpoint, which includes username, public email, and full name. Also grants access to read-only API endpoints under /users. ) read_api (Grants read access to the API, including all groups and projects, the container registry, and the package registry.)
а тут как? Просмотр информации о пользователе – ну, допустим. Просмотр информации о проектах пользователя – окей, Просмотр информации о реестре пакетов Создание пакетов реестра Удаление пакетов реестра
Где простой read_repository_only ? Дам все права сразу, потом разбираться буду.
Замечу, что кроме API токенов и транспортных токенов, в проекте есть еще какие-то токены развертывания, но перечня «есть три типа токенов» в руководстве нет. Или где-то дальше, как транспортные токены.
Впрочем, не важно. сообщение про токен читаемое, в моем случае:
Скопируйте токен. Он показан один раз и при перезагрузке страницы его получить иными способами не получится: af71db42-9683-40b4-b615-d31c9e5f7a16
Что с ними делать?
Для того, чтобы создать REST-API запрос, необходимо обратиться на определенный адрес (endpoint), который должен иметь следующее начало:
api.gitflic.ru для работы с API на gitflic.ru localhost:8080/rest-api для работы с API в self-hosted сборках
Домен и порт при работе с self-hosted решением могут отличаться.
Для взаимодействия с публичным API GitFlic необходимо указать полученный access token в заголовке запроса в следующей форме: Authorization: token <accessToken>
Что мешало написать пример для curl или хоть чего-то?
Делаем пример 01: Invoke-WebRequest -Uri 'http://192.168.21.61:8080/rest-api' -Method 'GET' -Headers $headers01 –Verbose Получим ошибку: Specified value has invalid HTTP Header characters. Parameter name: name
Делаем пример 02: Invoke-WebRequest -Uri 'http://192.168.21.61:8080/rest-api' -Method 'GET' -Headers $headers02 –Verbose Очевидно, тут в токене сознательно сделана ошибка, и результат: The remote server returned an error: (403) Forbidden.
Делаем пример 03 Invoke-WebRequest -Uri 'http://192.168.21.61:8080/rest-api' -Method 'GET' -Headers $headers03 –Verbose Результат: VERBOSE: GET with 0-byte payload Invoke-WebRequest : The remote server returned an error: (404) Not Found.
Ну … ладно. Оно, допустим, работает, но можно же было бы и вернуть «токен ОК, а дальше не знаем». Но ответ (404) Not Found - пугает.
Можно же было сделать пример для запроса «токен ок, запросите чего-то еще». Валидации токена не хватает. Или я не искал и не нашел. А он – есть.
Ответ содержит вполне понятный строчный объект, типа {"disableLdapAuth":false,"disableSamlAuth":false,"disableOidcAuth":false, и так далее}
Уже неплохо. Наверное, его можно даже распарсить в какой-то объект, но это не является темой для статьи
Через curl тоже работает: curl.exe --verbose --header "Authorization:token af71db42-9683-40b4-b615-d31c9e5f7a16" $Ad03 Ключ --verbose, конечно, мне был нужен только для отладки, и в таком виде только для читаемости Так что в windows можно делать $Ret032 = curl.exe --header "Authorization:token af71db42-9683-40b4-b615-d31c9e5f7a16" $Ad03
Ответ несколько непредсказуем. Заголовок – есть, ответ StatusCode: 200 есть, а внутри – ничего нет. Ни массива, ничего. Потому что публичных проектов у меня нет. Хотя бы вернули 200, а не (404) Not Found.
Метод для получения содержимого файла GET /project/{ownerAlias}/{projectAlias}/blob?commitHash={commitHash}&file={fileName} Запрос возвращает содержимое файла, который был изменен в указанном коммите, строкой. Если размер файла больше, чем 15МБ, или же он бинарный/картинка необходимо использовать следующий метод commitHash. Обязательный параметр. Хэш коммита, который хранит необходимое состояние репозитория
И как это понимать? Какой еще хеш коммита? Зачем ? Сравните для Gitlab :
И вот это. Какой еще коммит? Если мне надо не коммит, а всегда latest, то что?
Но, метод работает. Одна проблема, где взять хеш коммита. И вторая, как указать ветку, видимо по хешу. Очень странно. С хешем просто. Его можно получить двумя способами. Первый способ, простой. Нужно зайти в историю коммитов файла в GUI и справа будет 7 значный (почему 7 ?) номер коммита
Второй способ, чуть сложнее. Нужно ткнуть на RAW, откроется длинная ссылка вида http://192.168.21.61:8080/project/adminuser/mynewproject01/blob/raw?file=myfile01&commit=9e12345(длинный хвост) Первые 7 цифр в ID коммита – хеш. Остальное – даже не представляю, UUID какой-то.
--verbose, конечно, мне был нужен только для отладки, и в таком виде только для читаемости
Метод для получения списка файлов GET /project/{ownerAlias}/{projectAlias}/blob/recursive?commitHash={commitHash}&directory={directory}&depth={depth}
Запрос возвращает список файлов с информацией о них, начиная с определенной папки и до определенной глубины. Папки не возвращаются.
Опять commitHash. Опять «Обязательный параметр. Хэш коммита, который хранит необходимое состояние репозитория».
Заключение
Приложение работает, API работает. Документация вызывает ряд вопросов, но их уже без меня пусть бывшие коллеги решают. Получение файла и чего угодно вообще через хеш коммита, а не последней (текущей) версии файла выглядит крайне странно. Как и часть инструкции, где этот хеш коммита упомянут, а где его брать – нет. Не очевидно оформляется токен, где не совсем понятно, как сделать read_repository_only Как это будет работать с докером, ансиблом, и так далее – не проверял, и не хочу. Наверное, как-то работает.
PS. Пока писал статью: оказалось что дело было не в бобине, и коллеги и сами справились. Просто у них опять кое-кто накрутил с сертификатами, проверками, и прочей безопасностью, и не сознавался. Пока писал статью: программа набрала 10000000 очков в рейтинге - GitFlic признана лидером среди российских DevOps-платформ по версии CNews.
![🗓 28.12.1969 — Линус Торвальдс [вехи_истории]](https://cs18.pikabu.ru/s/2025/12/27/16/hldrdqwx.jpg)
