С главой VMware Дирком Хонделем на LinuxCon + ContainerCon + CloudOpen China в Пекине перед почти двухтысячной аудиторией Линус Торвальдс обсудил, что мотивирует и удивляет его в его деятельности, и как начинающим разработчикам открытого ПО найти работу. Linux.com опубликовал фрагменты этого разговора. Читать полностью »
Намного лучше дисциплинарные ограничения убирать инструментарным расширением
Автор статьи
При разработке информационной системы, то есть программы, нацеленной на хранение, работу с данными, обработку, анализ и визуализацию какой-то базы данных, одним из краеугольных камней стоит задача разработки БД. Когда я только начинал задаваться этим вопросом, казалось – что ни сделай, все равно будет криво.
На протяжении 5 лет разработки нескольких корпоративных ИС, я ставил и пытался решать вопросы, как тот или иной аспект разработки БД сделать удобным. Искал инструменты, помогающие что-то делать с БД, методологии. На удивление в этой области мало наработок. И в каждом подходе сразу видно – вот это нельзя, вот тут будет неудобно, тут слишком много дисциплинарных правил (см эпиграф)… В этой статье я попытался собрать те походы, которые считаю наиболее эффективными, и один, в добавление к собранным, представлю как венец моих исканий, который считаю наиболее «бронебойным».
Дано:
Требуется:
Консоль управления космическим кораблёмQA стендом
Вот приходишь ты работать в маленький стартап с американскими корнями…
Читать полностью »
Это вторая часть моего руководства о том, как самостоятельно администрировать Redmine в долгосрочной перспективе. Первая часть была посвящена управлению собственной версией Redmine с помощью Git (ссылка на перевод).
Имея собственный репозиторий Redmine, пришло время ...
Дисклеймер: это не обычное руководство вида «Как установить Redmine». В нем я не буду погружаться в настройку базы данных или установку веб-сервера. Я также не буду рассказывать о настройке Redmine. Документация по Redmine в этом плане является достаточно полной. А для того, что не упоминается в официальной документации, есть общая процедура запуска Rails-приложений, которую можно легко найти в Интернете.
Вместо этого речь пойдет о сопровождении собственной, более или менее кастомизированной версии Redmine, которая может быть развернута с помощью одной команды оболочки, когда это необходимо.
Готовы? Тогда начнём.
Привет! Предлагаю вашему вниманию перевод статьи Git Virtual File System Design History. Продолжение следует…
Виртуальная файловая система Git (Git Virtual File System, далее GVFS) была создана для решения двух основных задач:
В нашем случае основной сценарий использования GVFS — это репозиторий Windows с его 3 миллионами файлов в рабочей директории в сумме занимающих 270 Гбайт.Читать полностью »
GitLab спроектирован таким образом, что каждый участник проекта может вносить свой вклад, независимо от размера команды и местонахождения ее участников.
Зачастую в процессе разработки продукта несколько человек работают над одной задачей: например, разработчики фронтэнда и бэкэнда, дизайнер интерфейса, тестировщик и менеджер продукта. С выходом GitLab 9.2 все они могут быть назначены исполнителями одной задачи, что упрощает процесс совместной разработки и позволяет наглядно отображать их общую область ответственности.
Также в версии 9.2 положено начало процесса локализации GitLab: аналитика цикла разработки (Cycle Analytics) теперь доступна на испанском и немецком языках. Локализация GitLab будет продолжена в последующих релизах, чтобы каждый мог вносить свой вклад независимо от родного языка.
Кроме того, разработчики получили больше контроля над временем выполнения конвейеров CI/CD. Теперь можно составлять расписание выполнения конвейеров, что позволяет автоматизировать периодические задачи, такие как ночные сборки, профилактика или подтверждение внешних зависимостей.
Предлагаю читателям "Хабрахабра" перевод статьи "Хорошая практика в сообщении коммитов от OpenStack".
Следующий документ основан на опыте разработки кода, устранении ошибок и просмотре кода в ряде проектов, использующих Git, включая libvirt, QEMU и OpenStack Nova. Рассмотрение других проектов с открытым исходным кодом, таких как Kernel, CoreUtils, GNULIB а также других, предполагает, что все они следуют достаточно распространенной практике. Это мотивировано желанием улучшить качество истории Git проекта Nova. Качество — это абстрактный термин для определения в разработке; когда для одного человека некий код «Красивый» (Thing of Beauty) — то для другого это «Костыль» (Evil Hack). Тем не менее мы можем сформулировать некоторые общие рекомендации о том, как и что делать, или, наоборот, чего не делать, когда отправляют Git коммиты для слияния с проектами в OpenStack.
Эта тема может быть разделена на две области:
Прошло уже три месяца с тех пор, как я опубликовал свою первую статью о наших попытках масштабировать Git для очень крупных проектов при помощи инициативы, которую мы назвали «Git Virtual File System». Напомню: GVFS в сочетании с некоторыми правками в Git позволяет работать с ОЧЕНЬ большими репозиториями, виртуализируя как папку .git, так и рабочую директорию. Вместо того, чтобы скачивать репозиторий целиком и проверять все файлы, инструмент динамично скачивает только те фрагменты, которые вам нужны, выявляя их на основании того, над чем вы работали до этого момента.
За это время много чего произошло, и я хочу поделиться с вами новостями. Три месяца назад GVFS был только мечтой. Не в том смысле, что его не существовало — у нас была готовая реализация — но в том, что он еще не показал себя в деле. Мы опробовали его на больших репозиториях, но не успели внедрить в рабочий процесс для сколько-нибудь значимого количества разработчиков. Поэтому у нас было только умозрительное убеждение, что все будет работать. Теперь же у нас есть подтверждение этому.
Статья является вольным переводом вот этого материала: krisjordan.com/essays/setting-up-push-to-deploy-with-git. Любителям длинных и заумных первоисточников можно сразу читать оригинал.
Когда перед нами ставится задача при изменении кодбейса, например, в Github-репозитории выполнить пересборку/перезапуск какого-нибудь приложения на каком-то нашем окружении, то первое, что приходит на ум в качестве возможного триггера такой пересборки, это предоставляемый тем же гитхабом механизм веб-хуков: при наступлении какого-либо события с нашим удаленным репозиторием (т.к. появление нового коммита в какой-нибудь его отслеживаемой ветке) гитхаб задействует соответствующий веб-хук и «дернет» указанный в его настройках сервис, который и запустит процесс пересборки/перезапуска нашего приложения. Это стандартный широкоиспользуемый и простой механизм для таких случаев, все так делают, и все такое…
Но что, если наше приложение живет на хосте, доступ к которому по каким-то причинам гитхабу не положен? Например, хост находится в закрытой сети или за NAT'ом и недоступен из интернета?
Читать полностью »
