Системы управления версиями *

Любой, кто использует Git, знает, что у него крутая линия обучения. Мы узнали от разработчиков, что большинство людей, как правило, учатся у знакомых, будь то коллега, профессор, друг или даже видео на YouTube. В GitHub Desktop 2.2 мы добавляем первую версию интерактивного учебника по Git и GitHub, который может стать вашим другом и помочь вам начать работу. Если вы новичок в Desktop, вы можете скачать и попробовать учебник по адресу desktop.github.com.

Умение работать внутри системы контроля версий — навык, который требуется каждому программисту. Зачастую может показаться, что закапываться в Git и разбираться в его внутренностях — лишняя потеря времени и основные задачи можно решить через базовый набор команд.

Команде AppsCast, конечно, захотелось узнать больше, и за консультацией по практическому применению всех возможностей Git ребята обратились к Егору Андреевичу из Square.

Канареечный деплой — это очень эффективный способ тестирования нового кода на каком-то подмножестве пользователей. Он значительно снижает трафик-нагрузку, с которой могут возникнуть проблемы в процессе развертывания, так как происходит только в пределах определенной подгруппы. Эта заметка посвящена тому, как организовать подобный деплой средствами Kubernetes и автоматизации деплоя. Предполагается, что вы кое-что знаете о Helm и ресурсах Kubernetes.

1. Стоимость этикетировочной машины для весовой продукции сопоставима со стоимостью проекта внедрения MES-системы. Для простоты, пусть и то, и другое, будет стоить 7 млн. рублей.

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

Изложенный здесь подход, с примером конкретной реализации, имеет низкий порог вхождения. Технически, уже завтра вы можете начать работать по-новому.

Мы обратимся к ранним годам интернета, чтобы понять нынешнюю популярность динамических сайтов. Затем рассмотрим преимущества статических сайтов с точки зрения производительности, скорости редактирования и поисковой оптимизации.

Сначала была статика.

В первые дни интернет был обществом энтузиастов, разработчиков и инженеров. Несмотря на частые сравнения между MySpace и Facebook, эти два сервиса принципиально отличаются. Они также хорошо демонстрируют разницу в «интернет-парадигме» соответствующего времени.

И то, и другое — социальные сети, но создание страницы на MySpace требовало базового понимания HTML и CSS. В конце концов, сайт открылся в 2003 году. С другой стороны, простой в использовании интерфейс Facebook помог расширить аудиторию до двух с лишним миллиардов пользователей.

За антагонизмом MySpace/Facebook лежит критическая точка напряжённости в интернете: как взаимодействовать с контентом, который мы редактируем? Тут есть два основных способа.

Вышел GitHub Package Registry, сервис управления пакетами, который позволяет легко публиковать публичные или частные пакеты рядом с исходным кодом.

Реестр пакетов GitHub полностью интегрирован с GitHub, поэтому вы можете использовать те же инструменты поиска, просмотра и управления, чтобы находить и публиковать пакеты, что и при работе с репозиториями. Вы также можете использовать одни и те же пользовательские и командные права для совместного управления кодом и пакетами. GitHub Package Registry обеспечивает быструю и надежную загрузку, с поддержкой глобальной CDN GitHub. Кроме того, он поддерживает знакомые инструменты управления пакетами: JavaScript (npm), Java (Maven), Ruby (RubyGems), .NET (NuGet) и Docker (и другие на подходе).

Вы можете попробовать GitHub Package Registry сегодня в ограниченной бета-версии. Он всегда будет бесплатным для использования для Open-Source. Более подробная информация о ценах будет объявлена ​​в ближайшее время.

Попробовать бета-версию

Как обычно используют git? Пара базовых команд, чтобы «всех синхронизировать». Разочарование от git часто возникает у тех, кто никогда не выходит за пределы этого поверхностного понимания. Однако освоение git наверняка окупится. Сколько времени вы тратите на использование git? Я бы предположил, что на вашем поясе немало инструментов, которые вы используете вдвое реже и потратили вдвое больше времени на изучение.

Жизненный цикл программного обеспечения известен большинству современных программистов.

Даже школьник, написав свою первую программу

<?php 
echo "Hello, Хабр! На пхп"
?>

или

fprintf( 'Привет Хабр на Матлабе!\n');

понимает технологический процесс.

1. Думает над задачей — этап появления идеи
2. Думает над задачей и каким способом её нужно реализовать — Анализ и проработка требований,
   построение программной модели и плана на реализацию. Короче, архитектурный этап.
3. Программирование.
4. Тестирование. «А что там получилось»
5. Эксплуатация.

Между 1-5 этапами нитиобразно мы имеем непрерывно взаимодействующие процессы.

Для этого существуют всякие Водопады, Скрамы итд.

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

И по этой причине мы все наблюдаем обилие проектов, в которых одновременно существуют несколько типов фронэндов, взаимодействующих по API с централизованным бэкэндом.

Цель статьи — на примере библиотеки schema-keeper показать инструменты для упрощения разработки баз данных в PHP-проектах, использующих СУБД PostgreSQL.

Будут рассмотрены следующие вопросы:

1. В каком виде хранить дамп структуры БД в системе контроля версий (далее по тексту — VCS)
2. Как отслеживать изменения в структуре БД после сохранения дампа
3. Как переносить изменения в структуре БД на другие окружения без конфликтов и гигантских файлов миграций
4. Как наладить процесс параллельной работы над проектом нескольких разработчиков
5. Как безопасно деплоить большее количество изменений в структуре БД на production-окружение

Информация из этой статьи, в первую очередь, будет полезна разработчикам, которые по максимуму хотят использовать возможности PostgreSQL, но сталкиваются с проблемами сопровождения бизнес-логики, вынесенной в БД.

Статья не будет описывать преимущества или недостатки хранения бизнес-логики в базе данных. Предполагается, что выбор уже сделан читателем.

Поддержка SAST для JavaScript

Благодаря Static Application Security Testing (SAST) GitLab сканирует код и помогает обнаружить потенциальные уязвимости еще в конвейере. В релизе 11.8 мы добавляем в список поддерживаемых SAST языков JavaScript, на основе существующей поддержки node.js. Теперь можно просканировать любые файлы JavaScript, статические скрипты и HTML. Важной практикой в DevSecOps сейчас является сканирование изменений при каждом коммите, и с этим обновлением SAST мы покрываем один из самых популярных веб-языков, помогая пользователям раньше обнаруживать риски в коде на JavaScript.

Управление релизами стало намного проще

GitLab 11.7 представляет Релизы для планов начиная с Core. Пользователи теперь будут получать полный «слепок» релиза — исходный код со всеми артефактами проекта. Это избавляет от необходимости вручную собирать в одном месте исходный код, лог сборки, другие метаданные или артефакты, относящиеся к данному релизу. Эта фича послужит основой для более развернутого и проработанного управления релизами в будущем.

Всем привет!

Итак, новая порция обещанного холивара про монорепозитории. В первой части мы обсуждали перевод статьи уважаемого инженера из Lyft (и ранее Twitter) о том, какие есть недостатки у монорепозиториев и почему они нивелируют почти все достоинства этого подхода. Лично я во многом согласен с доводами, приведенными в оригинальной статье. Но, как и обещал, чтобы поставить точку в этом обсуждении, я бы хотел озвучить еще несколько моментов, на мой взгляд даже более важных и более практических.

Мы рады представить релиз GitLab 11.6, в котором мы расширили возможности бессерверной архитектуры на GitLab и добавили групповые кластеры Kubernetes для упрощения работы с нативной облачной инфраструктурой.

Сегодня мы анонсируем два важных нововведения на GitHub, которые сделают его более доступным для разработчиков: неограниченные бесплатные приватные репозитории и более удобный продукт для компаний. Подробности под катом!

Эта новость опубликована на The Next Web, с пометкой:

"Из-за ошибок в планировании, мы опубликовали эту новость на день раньше снятия эмбарго на разглашение. Фича всё ещё не запущена, о ней официально расскажут завтра. Когда это произойдёт, мы обновим пост новым официальным анонсом".

А ещё есть вот такой замечательный тред в Twitter:

Ясно, что человек писал это дрожащими руками — точно так же, как я сейчас пишу дрожащими руками этот перевод.

Фейк ли это? Нет. Есть и официальное подтверждение в твиттере GitHub, так что — назад дороги нет.

Фичу явно выкатывали на спех, до сих пор на сайте не поправлена часть текстов, касающихся тарифов, а попытка даунгрейднуть план встречает таким вот опасно выглядящим сообщением:

В общем, запасаемся попкорном, скрещиваем пальцы на ногах и ждём годноты!

От переводчика: Привет, Хабр! Да, это очередная статья о преимуществах и недостатках монорепозиториев. Собирался написать свою статью о том, как мы используем монорепозиторий, как мы переходили с maven на bazel и что из этого получилось. Но пока собирался с мыслями, вышла отличная статья от разработчика из Lyft, которую я и решил для вас перевести. Обещаю опубликовать свои дополнения к статье, а также опыт с bazel в виде продолжения.

Мы в Новом 2019 году, и я настроен на еще одну дискуссию о преимуществах (или отсутствии таковых) в хранении всего исходного кода организации в «Монорепозитории». Для тех из вас, кто не знаком с этим подходом, идея состоит в том, чтобы хранить весь исходный код в едином репозитории системы контроля версий. Альтернатива, конечно, заключается в том, чтобы хранить исходный код в нескольких независимых репозиториях, разделяя их обычно по границе сервисов/приложений/библиотек.

В данном посте я буду называть такой подход «полирепозиторий».

При наличии работоспособного NAS с докером, установка Gitlab не представляет особых сложностей.

В этой статье я расскажу об одном полезном, но малоизвестном приеме работы с git — как можно легко создать коммит, используя дерево из другого коммита. Проще говоря, как получить нужное состояние проекта на какой-либо ветке, если это состояние уже когда-то и где-то было в репозитории раньше. Будет приведено несколько примеров того, как это позволяет элегантно решать некоторые практические задачи. И в частности я расскажу о найденном мной методе, который позволяет значительно упростить исправление множественных конфликтов при rebase. Кроме того, эта статья — отличный способ понять на практике, что из себя представляет коммит в git-е.

Панель управления безопасностью в рамках группы

Разработчики уже давно используют GitLab как инструмент для обеспечения безопасности своего кода. Теперь GitLab дает больше прав и возможностей специалистам, отвечающим за безопасность, так что они могут использовать его для повышения безопасности приложений и обеспечения совместимости. С релизом 11.5, новая панель безопасности группы собирает воедино всю информацию, которая может потребоваться специалистам по безопасности, в удобном виде, разработанном специально для них. Эта панель содержит новые возможности отображения: общий обзор информации о безопасности разных проектов, а также углубленная информация о каждом из них. В 11.5 мы начинаем с отчетов SAST, в дальнейших релизах будем добавлять новые отчеты на эту панель. Наша цель — создать удобный инструмент, единую панель безопасности, которую специалисты по безопасности смогут использовать вместо переключения между множеством инструментов.