Git *

Актуальность конфигурационных файлов – основа основ стабильной работы сети и активного оборудования. Раньше конфигурационные файлы можно было просто копировать автоматизированным способом при помощи специальной утилиты, и этого вполне хватало для успешного восстановления после замены вышедшего из строя оборудования. Но появились новые задачи, это связано с тем, что многие вендоры начали развивать технологию Infrastructure as Code (IaC).

То есть, можно описать свои действия с устройством с помощью кода, а затем его применить, а не использовать интерфейс командной строки или GUI интерфейс. Это существенно уменьшает вероятность ошибки при каких-либо манипуляциях при управлении устройством. В связи с этим возникла другая задача – как отслеживать актуальность и историю изменений в данном коде. Центр информационных технологий РТ стал использовать систему контроля версий, так же как её используют большинство программистов.

Сегодня речь пойдет про Git.

 Что такое «система контроля версий» и почему это важно? Система контроля версий – это система, записывающая изменения в файл или набор файлов в течение времени и позволяющая позже вернуться к определённой версии.

Сам Git является распределенной системой контроля версий (Distributed Version Control System, далее DVCS). В DVCS клиенты не просто скачивают снимок всех файлов (состояние файлов на определённый момент времени) – они полностью копируют репозиторий. В этом случае, если один из серверов, через который разработчики обменивались данными, умрёт, любой клиентский репозиторий может быть скопирован на другой сервер для продолжения работы. Каждая копия репозитория является полным бэкапом всех данных.

В этой статье речь пойдёт о том, как при помощи протокола ssh удобно и безопасно работать с удалёнными git-репозиториями.

Всем привет! Меня зовут Маша, и я Golang Backend Developer в компании Ozon. В этой статье я хотела бы поговорить о теме, так или иначе объединяющую все сферы нашего любимого мира IT. А именно — VCS Git.

Без системы контроля версий сейчас невозможно представить ни один проект. Это оплот любой кодовой базы, это мощнейший инструмент, с помощью которого эту базу можно изменять и отслеживать. Однако нередко чистотой истории изменений пренебрегают, полагаясь на старое доброе «И так сойдёт!», абсолютно игнорируя при этом сложность понимания и поддержки такой истории в будущем.

В этой статье я рассмотрю причины такого подхода, его недостатки, а также способы решения проблем, к которым он приводит. Я  выделила несколько основных принципов, которые помогут прийти к чистой истории изменений проекта. Давайте же вместе исследуем эту темную, неизведанную сторону Git, которая нам в этом поможет.

Хочу поделиться опытом ведения макетов, так чтобы это было похоже на Git, которым пользуются все разработчики.

Во время работы над сценариями возникает множество неоднозначных моментов, для которых нет четких инструкций, и порой приходится придумывать как работать так, чтобы было удобно тебе и твоей команде. А как быть, когда вы огромная корпорация, с несколькими десятками дизайнеров и сотнями разработчиков, макеты размножаются с такой скоростью, что если вести всё в одном файле, он может начать лагать уже через несколько недель. Отчасти поэтому мною и была разработана система хранения макетов, которую в последствие приняли во всем банке как стандарт. Самое главное — к этой системе я приложил подробный гайд, чтобы у всех дизайнеров была одинаковая логика ведения сценариев.

Привет! Я Даша, Android-разработчик в команде онлайн кинотеатра PREMIER.

В прошлой статье я рассказывала, как мы настроили сборку проекта с помощью Gitlab CI. Дальше нужно отправить приложение в маркеты для внутреннего тестирования, а затем конечным пользователям.

Сегодня разберемся, как автоматически опубликовать приложение в Google Play, Huawei App Gallery и Firebase на примере нашего приложения онлайн-кинотеатра PREMIER. Также расскажу, как мы отправляем сборку в Nexus.

В этой статье я расскажу о том, как и зачем подписывать и верифицировать коммиты в git при помощи gpg.

Сегодня мы с радостью объявляем о новом релизе GitLab 16.1 с полностью изменившимся опытом навигации, GitLab Dedicated в общем доступе, визуализацией ресурсов Kubernetes, аутентификацией через сервисные аккаунты и многими другими фичами!

Первая проба пера одного пира. Казанский кампус Школы 21.

Как мы учились настраивать работу с репозиторием в групповых проектах.

Привет, меня зовут Панов Михаил, я DevOps‑инженер МТС Digital. Хочу поделиться с вами опытом построения «модульных» pipelines на основе gitlab-ci. В этой статье я расскажу, что такое модульный CI/CD, из чего он состоит, для чего нужен и как поможет командам, поддерживающим большой список нетиповых репозиториев.

В статье я рассказываю, как в репозитории веб-сервиса «GitHub» можно переименовать сразу множество файлов одним коммитом.

У меня небольшой учебный репозиторий, с которым я работаю через веб-интерфейс. Через веб-интерфейс можно переименовывать файлы по одиночке, но иногда появляется необходимость переименовать сразу много файлов по одному и тому же принципу. Операция переименования состоит из нескольких этапов: клонирование репозитория на свой компьютер, написание скрипта для переименования множества файлов и запуск переименования, создание коммита и отправка изменений в оригинальный репозиторий на «GitHub».

По ходу дела я касаюсь работы с «Git» из командной строки, немного разбираю настройку Git-репозитория, пишу скрипт на языке PowerShell, работаю с регулярными выражениями и создаю гранулированный токен доступа в «GitHub».

В былые времена для разработки проекта программисту нужен был только редактор для написания кода и компилятор. Но сейчас любой сколько-нибудь серьезный проект требует привлечения команды разработчиков и тестировщиков и соответствующих средств для контроля версий. Наиболее распространенным решением для управления версиями является Git. Данная система позволяет управлять версиями в рамках большого количества различных проектов по разработке ПО, при этом Git можно использовать как в коммерческих, так и в проектах с открытым исходным кодом. Также, стоит отметить, что Git используется множеством профессиональных разработчиков программного обеспечения и она превосходно работает под управлением различных операционных систем и может применяться со множеством интегрированных сред разработки.

Какие преимущества дает использование Git командой разработчиков? Прежде всего это централизованное хранение версий файлов исходных кодов проектов. Причем, речь идет не просто о хранении последней, актуальной версии того или иного кода, но и о хранении всех предыдущих версий кода. Иногда это бывает очень полезно. Так, например, с помощью Git разработчик может откатить свой проект до более старой версии, для того, чтобы сравнить или проанализировать свои изменения в коде проекта.

Хранилища кода являются неотъемлемой частью современной разработки ПО. Они позволяют командам разработчиков управлять своим кодом, устанавливать версии и совершенствовать процесс разработки. Современные реалии внесли свои коррективы в работу, заставив в короткие сроки перейти на российские аналоги ПО.

В статье Центр цифровой трансформации РТ рассказывает о своем опыте импортозамещения платформы Bitbucket на отечественный софт, о выявленных плюсах и минусах, и о сделанных выводах.

Мы продолжаем серию статей о применении подхода GitOps к инфраструктуре нашей организации. Первую часть можно почитать тут.  

Я – ведущий DevOps инженер в IT-хабe группы компаний Dyninno. Мы (команда больше 300 человек) занимаемся разработкой ПО и отвечаем за IT инфраструктуру всех компаний группы. Dyninno – международный холдинг, который работает в трех сегментах бизнеса: авиаперелеты, финансовый сектор и индустрия развлечений (кастинг актеров). В прошлой статье я рассказывал о нашем переходе на GitOps, а сегодня хочу остановиться подробнее на управлении инфраструктурой в рамках этого перехода. Эта статья может быть интересна тем, кто задумывается о внедрении GitOps в свою инфраструктуру.  

Разработчикам несомненно надо уметь работать с Git и делать это через командную строку. Иногда бывают ситуации, когда просто нет возможности установить на машину альтернативный инструмент с графическим интерфейсом. При этом некоторые задачи удобнее выполнять в специализированных приложениях, и никто не запрещает использовать GUI в собственных проектах.

В этой статье собраны самые популярные графические интерфейсы Git. Есть как бесплатные инструменты с открытым исходным кодом, так и проприетарные решения с дорогими лицензиями. Некоторыми клиентами из статьи я пользовался сам, чтобы в итоге выбрать удобный вариант для своих задач.

Тема "Windows vs Linux" является частой причиной холиваров. Спорить бессмысленно, так как для каждой задачи требуется свой инструмент. Позвольте заинтересовать вас чудесным миром Linux и теми бонусами, которые вы можете получить от использования терминала в повседневной деятельности. Всё разберём на примерах реального использования.

Инструкция написана для сервиса github. Вам нужно войти в свой аккаунт или зарегистрироваться.

Все команды вводятся в терминале.

Шаг 1

Делаем fork (копию) нужного проекта. Переходим в свой аккаунт и заходим в только что созданный fork.

Дисклеймер: B первую очередь материал будет интересен тем, кто уже значительное время занимается тестированием пользовательского интерфейса и не знает, как подойти к тестированию backend части приложения. Я не претендую на истину: всё, что сказано ниже, является моим субъективным мнением и пережитым опытом.

Введение

Рынок IT специалистов начал стремительно развиваться в последние пару лет. Требования ко всем специальностям, которые задействованы в разработке программного обеспечения, растут со скоростью развития применяемых технологий. Требования выросли и к специалистам по тестированию. Например, если ещё в 2019 году для того, чтобы устроится тестировщиком в международную IT компанию достаточно было иметь год опыта тестирования чего-нибудь, прочитать «Тестирование dot com» Савина, уметь писать тест-кейсы, знать такие слова как «GIT», «SQL» и «Redmine», то в 2021 году ситуация стала радикально меняться. Осознание того факта, что пятилетний опыт ручного тестирования frontend части различных приложений недостаточен для конкурирования на рынке, привёл меня к выгоранию и побудил к решительным действиям. Я осознал, чтобы не остаться на обочине всей IT индустрии необходимо соответствовать современным критериям хорошего специалиста по тестированию. А именно, попытаться понять, как тестировать серверную часть приложений.

В этом материале я не ставлю себе задачу объяснить все тонкости такого вида тестирования. Я хочу лишь познакомить с моментами, которые смогут вам помочь легче воспринимать этот процесс. Также постараюсь передать свой опыт вхождения в backend команду, рассказать о том, что помогло мне не сойти с ума от большого количества новой информации и с какими инструментами возможно придется столкнуться на таком проекте, а также, что поможет безболезненно выполнять сложные задачи.

Как я сделал удобный автодеплой ui-kit на npm с помощью pipeline's gitlab.

Что удалось сделать?

• Автоматическое обновление версии пакета при пуше изменений.

• Автоматический деплой новой версии на npm.

Про CI/CD написано много разных статей и в них рассказывают о том, как это помогает увеличить TTM (time to market), позволяет автоматизировать рутинные вещи (например автотесты и различные проверки) и как деплоить в продакшен без отказа в обслуживании.

Мы в more.tv — не исключение и тоже стремимся к улучшению этих показателей при организации CI/CD.

Я Дмитрий Зайцев — руководитель отдела DevOps, и в этой статье расскажу вам, по какому пути прошли мы, какие особенности есть в нашей работе, какие задачи решали на каждом этапе и к чему в итоге пришли.   

Сразу отмечу — мы используем Gitlab, поэтому все процессы будут описаны именно в контексте использования Gitlab CI/CD.