Немного истории

В самом начале 2010 года Vincent Driessen пишет отличную статью A successful Git branching model. Для понимания того, о чем пойдет речь дальше, со статьей нужно, конечно же, познакомиться. А для тех, кому сложен язык оригинальной статьи, на хабре есть её отличный перевод.

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

• Плагин к самому Git'у
• Плагины к различным IDE: IDEA, Eclipse
• Встроенная поддержка в GUI клиентах: SourceTree и Git Extensions
• Плагины для систем сборки: Maven, Gradle, и т.д.
• Встроенная поддержка в менеджерах репозиториев: GitHub, BitBucket, GitLab и т.д.

Кажется, что модель идеальна. Быть может так оно и есть, если у вас небольшая команда, неизменяемый скоуп релизов, высокая культура работы с VCS. Тогда, действительно, GitFlow может и удовлетворит все ваши потребности. Но, к сожалению, описанные условия подходят не всем командам и не всем проектам. К слову, найти статьи, в которых бы авторы описывали проблемы этой модели не так уж и просто даже в 2016 году. Но как мы все знаем, серебряной пули нет, а, значит, и в этой модели всё хорошо далеко не для всех.

Всем привет! Очередной выпуск статьи из цикла «Как мы внедряли DevOps» от команды Vorlon.JS. Vorlon.JS — это основанный на node.js инструмент, который позволяет веб-разработчикам удобный способ удаленно тестировать, контролировать и отлаживать веб-приложение, особенно на мобильных и embedded системах. В своем блоге на MSDN, команда описывала поэтапное внедрение DevOps практик в организацию работы над Vorlon.JS и выбор инструментов для решения ежедневных задач. Vorlon.JS является проектом с открытым исходным кодом.

Содержание цикла:

• Планирование и управление проектами с помощью Visual Studio Team Services
• Непрерывная интеграция с GitHub и системой сборки Visual Studio Team Services
• Инфраструктура-как-код с помощью Microsoft Azure и Azure Resource Manager
• Управление релизами в Visual Studio Team Services
• Тестирование в production-среде с Microsoft Azure App Service и Web Apps

В предыдущих статьях этой серии мы обсуждали использование непрерывной интеграции, которая позволяет выполнять сборку кода при каждом изменении кода в GitHub, с помощью системы сборки в Visual Studio Team Services. Кроме того, эта сборка генерирует ряд артефактов: код приложения с его зависимостями и скрипты (в папке DeploymentTools), позволяющие автоматически создать инфраструктуру (по принципу «инфраструктура-как-код») в Microsoft Azure и развернуть приложение.

Bitbucket Server (ранее известный как Stash) — решение для централизованного управления разработкой, позволяющее управлять вашими репозиториями, в том числе не открывая доступа к ним извне организации. Bitbucket позволяет упростить хранение репозиториев с исходными кодами на вашем сервере и обеспечивает простоту доступа к репозиториям для всех членов вашей команды.

В мире IT известно, что Bitbucket может быть проинтегрирован с другими продуктами и платформами в единую экосистему, которая делает процесс разработки всеобъемлющим и удобным. Чаще всего Bitbucket интегрируется с JIRA. Однако, поиск и локализация проблем — не единственная задача, с которой типовой процесс разработки сталкивается каждый день, и даже несколько раз в день. Более важной задачей является сохранение целостности проекта в процессе внесения дополнений и исправлений в код. Для этих задач вы можете использовать CI-сервер, который в том числе позволяет создавать сборки проектов и выполнять серии тестов для автоматической проверки функциональности.

Bitbucket «из коробки» предлагает интеграцию с родственным решением от Atlassian — Bamboo. Но, помимо Bamboo, существуют другие CI-решения, которые также достаточно популярны — TeamCity и Jenkins. В нашем посте мы обрисуем специфику интеграции Bitbucket и TeamCity.

Приветствую,

Поиск по архивам Хабра показал, что о Perforce Helix почти ничего не писали, а в рунете доступна только обзорная статья про расширение для VS и перевод англоязычной старенькой статьи Dear Perforce: fcuk you. При этом в комментариях к статье, посвящённой используемым системам контроля версий, Perforce часто упоминали, поэтому мне захотелось опубликовать пару обзорных статей по функциональности Perforce Helix, которые возможно кому-то помогли бы разобраться в данной платформе, то есть исключительно для информационной составляющей.

За все время опыта веб-разработки приходилось сталкиваться с различными хостингами на которых работали сайты: от тех, на которых поддерживаются только текстовые форматы (а-ля narod.ru) до виртуальных машин, на которых есть root доступ.

Относительно недавно столкнулся с проблемой: велась разработка сайта на shared хостинге, имеющем достаточный набор технологий для обычного сайта для контента вроде новостей. Одной из существенных проблем стало отсутствие системы контроля версий. Установить ее традиционным способом не представлялось возможным. Были начаты поиски пути для решения этой проблемы.

Задача была выполнена, и как она была решена — пошагово описано ниже.

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

Предисловие

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

Приведенный ниже сценарий обрабатывает статусы состояний только антивирусов, используемых в нашей корпоративной сети.

18 февраля в Москве, мы традиционно провели нашу ежегодную конференцию по решениям Microsoft в области управления жизненным циклом разработки программного обеспечения. В этом году ALM Summit состояла из основного трека и круглых столов, на которых были затронуты следующие тематические направления:

• Инфраструктурные решения ALM в облаке, которые позволяют быстро развернуть комплекс ALM инструментов и в считанные часы запустить проект.
• Методологические рекомендации по ведению проектов, SCRUM, Kanban, Agile, сбор информации о ходе проекта, ее анализ и отчетность.
• Обеспечение качества разрабатываемых систем с помощью тестирования, как построить эффективную среду тестирования с помощью инструментов Team Foundation Server и Team Foundation Services в облаке.
• Эксплуатация разрабатываемых систем, обеспечение обратной связи для повышения качества.

Как обычно, мы транслируем и записываем конференцию.

И рады сообщить, что записи доступны для просмотра!

Меня зовут Оксана Харчук, я работаю QA-инженером в DataArt чуть больше года. Расскажу, как в нашем проекте организован процесс работы, и как быть, если релиз каждый день.

Сначала, когда я только пришла в DataArt, слово «релиз» ассоциировалось у меня с чем-то страшным. Но, как оказалось, если процесс работы построен правильно, релизы даже каждый день — совсем не страшно, а очень даже удобно.Чтобы этого достичь, процесс разработки в нашем проекте построен на принципах непрерывной поставки (continuous delivery) и непрерывной интеграции (continuous integration).

Что такое Continuous delivery и Сontinuous integration?

Continuous delivery или непрерывная поставка ПО — набор практик и принципов, нацеленных на сборку, тестирование и поставку ПО быстрее и чаще. Непрерывная поставка качественного кода опирается, в свою очередь, на непрерывную интеграцию.

Сontinuous integration, или непрерывная интеграция — это практика разработки ПО, которая заключается в выполнении частых автоматизированных сборок проекта для скорейшего выявления и решения интеграционных проблем. Ведь ясно: если над разными частями кода работают несколько программистов, при интеграции этих частей возникает много трудностей. Непрерывная интеграция помогает справиться с ними.

При эксплуатации системы GitLab CE на своем предприятии (имеющему большую филиальную структуру), была обнаружена уязвимость, которая может привести к получению полного доступа к аккаунту любого пользователя системы администраторами филиалов предприятия.

Проблема выявлена в подсистеме LDAP-аутентификации пользователей. Дело в том, что основной сущностью, с использованием которой происходит авторизация в GitLab является E-Mail пользователя. Однако при входе пользователей в GitLab с использованием LDAP процесс аутентификации/авторизации происходит следующим образом:

• Пользователь вводит на странице Sign-In системы свои имя/пароль из службы каталогов LDAP (Active Directory).
• GitLab, используя введенные данные аккаунта производит аутентификацию пользователя в LDAP.
• В случае успешной аутентификации GitLab считывает из атрибута MAIL аутентифицированного аккаунта адрес электронной почты и авторизует по нему в GitLab без всяких дополнительных проверок

.
В результате, например, «нехороший» системный администратор «филиала A», может используя свои полномочия, к примеру в Active Directory, создать в своем OU «Филиал А» любого пользователя (например hackuser) и записать в его LDAP-атрибут MAIL адрес электронной почты пользователя любого другого филиала, на который даже не распространяются полномочия этого администратора. После этого «нехороший» администратор «Филиала А» может авторизоваться пользователем hackuser в системе GitLab, при этом в результате авторизации будет получен полный доступ к аккаунту пользователя, имеющего адрес электронной почты установленный «нехорошим» администратором для hackuser.

Когда я познакомился с Mercurial, то все свои знания я почерпнул из статей Спольского (перевод на Хабре), которые подробно описывают основные принципы работы Mercurial и ежедневную работу с ним. Долгое время я использовал Mercurial в пределах, которые не превышали объема этих статей. Наверно, для одиночного разработчика этого почти достаточно. Почти. Но Mercurial сегодня значительно шире и обладает возможностями допускающими редактирование истории изменений, наличие которых, в общем-то, не очевидно, хотя возможности эти достаточно ценны. А из комментариев к разным статьям по системам управления версиями видно, что многие разработчики об этих возможностях не знают. Ниже я хочу провести обзор ряда возможностей Mercurial связанных с изменением истории.

О чем пойдет речь:

• фазы
  
• hg commit –amend
  
• hg strip
  
• hg rebase
  

На работе в рамках проектирования новой системы интеграции устройств для мониторинга аудио/видео потоков возникла задача отслеживания, накопления и последующего анализа изменений их состояния. Состояние выдаётся через зоопарк динамических XML-документов, используемых, в основном, для наполнения legacy web-UI.

Для упрощения интеграции мною была предложена идея создания обобщённой библиотеки для сохранения структурированных diff-ов для (почти) произвольного XML. Поскольку эти diff-ы будут сохраняться с учётом структуры документа, это дало бы возможность очень экономно аккумулировать изменения состояния устройств, а также в будущем генерировать отчёты с аналитикой, диаграммами, и т.п. После недели запойного программирования я набросал работающий proof-of-concept, которым и хочу поделиться в данной статье.

Я очень долгое время ходил вокруг NOC и облизывался на него, как та лиса на виноград. Ставил, тыкался и бросал. А потом снова возвращался, ибо прельщал подлец своими возможностями. И понимание того, что именно его не хватает в жизни для «щастья» в конце концов заставило зажать нервы в узду и взяться за NOC всерьез.

Если кто-то еще не знает что такое noc project, то это центр управления сетевой инфраструктурой. Программа позволяет организовать контроль за сбоями, слежение за производительностью, активацию сервисов, ведение базы знаний, управление адресным пространством, управление виртуальными сущностями (VLAN, DLCI), архивирование и ведение базы конфигураций, обеспечение работы DNS, генерацию отчетов. Вот тут можно про него почитать, офигеть от его крутости и вернуться сюда. А конкретно здесь я чуть-чуть расскажу про особенности установки, немного коснусь темы добавления оборудования, слегка углублюсь в вопросы его настройки, пробегусь по некоторым функциям этого программного комплекса и закончу на чем-нибудь позитивном или не очень. Как получится :)

Не так давно мой коллега переводил интересную статью о code review, перевод хабражителям понравился. А сегодня утром запутанный граф кроссылок вывел eyeofhell на еще более крутую статью. Вашему вниманию предлагается перевод краткой, но емкой инструкции о том, как делать review чужого кода и пережить review собственного. В отличие от упомянутой выше статьи, эта больше фокусируется на практических аспектах code review и содержит множество полезных рекомендаций как и что делать, чтобы не было мучительно больно. Хинт: чтобы почитать оригинал, кликните на имени автора в плашке под переводом.

Недавно прошло виртуальное мероприятие по Visual Studio 2015, на котором анонсировали много хорошего, и некоторую часть даже представили коллеги из Google. Обзор новостей мы написали достаточно оперативно, прямо после мероприятия, но этого, разумеется, оказалось недостаточно, и мы решили не только написать, но и записать!



4 декабря в 10:00 по МСК мы проведем виртуальное мероприятие Visual Studio Connect в России, где расскажем о некоторых новых возможностях Visual Studio 2015, связанных с облачной, веб, кроссплатформенной и игровой разработкой, а также инструментами тестирования и тем, как в Visual Studio можно использовать контейнеры. Присоединяйтесь!

Всё самое интересное из первых рук! Открытие конференции Microsoft Connect(); //2015 в 18:00 по Москве. Самые интересные анонсы для разработчиков из первых рук. Смотрите выступления Скотта Гатри, Брайна Харри и Скота Хансельмана.

Год назад на конференции Connect(); мы начали рассказывать историю новой Microsoft для разработчиков, объявив о будущем .NET с открытым исходным кодом для Linux и Maс и бесплатной Visual Studio, позволяющей разрабаывать для любого устройства и операционной системы.

Присоединяйтесь к нам в 18 ноября, чтобы из первых рук, от Скотта Гатри, Брайна Харри и Скота Хансельмана узать захватывающее продолжение этой истории. После открытия конференции, подробнее обо всех новых возможностях можно будет узнать из более чем 70 докладов, доступных по запросу.

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

В этой статье я постараюсь описать, как мы это всё используем в ежедневной работе всего коллектива разработки.

На протяжении 4-х лет у нас выработался следующий формат команды разработки:

• 1 Project Manager, он же Product Manager, он же Delivery Manager.
• 4-5 программистов
• 1 Team lead
• 3-4 QA
• 1 Аналитик
• 1 Техпис (иногда он же и аналитик в одном лице).

В итоге команда размером около 10-11 человек. Таких команд (ячеек) у нас несколько.

Работа в основном в стиле стартапа, когда нет конкретной и подробной постановки. Очень часто эксперименты вроде “а давайте попробуем так, посмотрим что получится” или “вы классно все сделали, но теперь надо все совсем по-другому”.
За эти годы концепцию нашей работы можно описать одной фразой — это “стремительная смена концепции”.
Понятное дело, что применить в таких условиях различные методологии никак не удавалось.

Начинал в этой системе я как программист, потом Team lead, ну а теперь PM (DM). Т.е. руковожу, полностью участвую в проектировании и иногда даже пописываю. Во времена моего программирования у меня был замечательный ПМ (выходец из тестировщиков), которая поддерживала все мои идеи по автоматизации workflow. Даже более того, концептуально этот процесс придуман ей, а я уже смог его технически реализовать и в некоторых местах усовершенствовать.

Очередная (2012, 2011, 2010, 2009) перепись в сфере VCS.

Cколько времени я использую GitFlow и Semantic Versioning, меня все не покидает чувство, что чего-то в них не хватает. Обе концепции хороши, но так как они предлагают решения для проблем из разных областей, их совместное использование выглядит сложнее, чем должно быть.

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