Кілька днів тому співробітники компанії Google і Центру математики та інформатики в Амстердамі представили перший алгоритм генерації колізій для SHA-1. За десять років існування SHA-1 не було відомо ні про одному практичному способі генерувати документи з таким же сумі SHA-1 і цифровим підписом, як в іншому документі, але тепер така можливість з'явилася.

Хеш-функція SHA-1 використовується повсюдно, тому звістка про генерації документів з ідентичним хешів викликало природну стурбованість у користувачів. Зокрема у користувачів системи контролю версій Git, в якій теж використовуються хеш SHA-1. Розгорнуту відповідь на ці побоювання дав Лінус Торвальс. Якщо коротко, то боятися нічого.

Читати далі →

Як тестувати контейнери RoR з GitLab CI у контейнері

Чим гарний GitLab, так це тим, що будучи за габаритами слоном у посудній лавці, він вміє акуратно встановлюватися і майже завжди працює з коробки. Але погано вміє відновлюватися і дбати про себе, коли дуже прямі руки начебто моїх порушують звичне йому оточення. Не буду заглиблюватися в те, як мені вдавалося вбити його до стану, коли навіть видалення та встановлення з нуля не допомагає, але під уникнення черговий нескінченної епопеї з дебагом і перевстановлення сервера я виніс все це справа в Docker контейнер. Зручно — на робочій машині немає мільйона залежностей, примонтировал директорії для репозиторіїв, журнали та бази даних і все працює. Відновлення — перезаснувати контейнер і згодувати бекап (до речі, не забудьте перевірити свої бекапи, як свідчить досвід GitLab, це не зайве).

З іншого боку, є розроблювальна Rails додаток, яке на реальній машині тримає тільки код; Rails, gems, і все інше спочиває в Docker контейнері. Для своєї роботи вона використовує Redis і Postgres, кожен знаходиться на своєму контейнері. Для кожного контейнера примонтирована директорія, щоб важливі для додатка дані не залишалися всередині.



Завдання в тому, щоб Gitlab CI нормально відпрацював. Начебто все просто, але — він сам знаходиться в контейнері.

Читати далі →

Огляд self-hosted continuous integration систем

Введення
Важко уявити сучасну розробку без Continuous Integration. Багато компаній випускають по кілька релізів в день і проганяють тисячі тестів. З часів Jenkins і Travis CI на ринку з'явилося багато різноманітних інструментів. Більшість з них працюють за моделлю SaaS — ви платите фіксовану плату за використання сервісу, або за кількість користувачів.
Але використання hosted платформ не завжди можливо, наприклад, якщо не можна передавати код додатка, або не хочеться залежати від зовнішніх сервісів. У такому разі виручають системи, які можна встановити на своїх серверах (self-hosted). Бонусом ви маєте повний контроль над ресурсами і можете масштабувати їх відповідно до ваших потреб використовуючи, наприклад, amazon ec2.
У цій статті представлений огляд декількох opensource self-hosted continuous integration систем, а також особисті враження від їх використання.

Читати далі →

OpenShift + Jenkins + Bitbucket, безперервна інтеграція та публікація з коробки


У цій статті я покажу, як швидко розгорнути середовище для збірки, тестування і публікації додатків використовуючи платформу OpenShift на прикладі PHP проекту. Використовувати буду OpenShift online, але все це можна розгорнути і на власних серверах або в VirtualBox (є готова збірка). Git-сервером для зберігання і версионирования коду буде Bitbucket.


Читати далі →

Вийшов GitLab 8.12

Поза залежності від масштабу вашого проекту, ваш інструментарій повинен:
а. бути зручним у роботі
б. давати корисну зворотний зв'язок.
В цьому місяці GitLab став краще по кожному з цих пунктів. GitLab 8.12 дає вам зворотний зв'язок про ефективність вашої роботи, допомагає шукати потрібний код по всій кодової базі, дозволяє убезпечити ваш робочий процес всього одним кліком і робить багато іншого.

Читати далі →

Gogs: легкий git-сервіс



У числі найбільш обговорюваних останніх новин в співтоваристві розробників були нові тарифи GitHub (див., наприклад, тут).

Звичайно, у нових тарифів є свої переваги, але з нинішнім курсом долара їх навряд чи можна назвати вигідними для російських користувачів.

Деякі вдаються до альтернативного рішення і розгортають GitLab (або інший git-сервіс) на власному чи орендованому сервері.

Але й у цього рішення є свої підводні камені: GitLab дуже вимогливий до системних ресурсів. Для приватних осіб набагато простіше платити 7 доларів в місяць за GitHub, ніж орендувати сервер належної конфігурації.

Зі сказаного, однак, не випливає, що у GitHub на сьогоднішній день альтернативи немає. Про один досить цікавий і перспективний рішенні ми хотіли б розповісти в цій статті. Знайомтеся: Gogs. Цей інструмент буде цікавий як для індивідуальних розробників, так і для невеликих компаній.

Читати далі →

Rebase Flow. Спосіб приготування і його підтримка в GitHub, GitLab, BitBucket

Трохи історії
В самому початку 2010 року Vincent Driessen пише чудову статтю A successful Git branching model. Для розуміння того, про що піде мова далі, зі статтею потрібно, звичайно ж, познайомитися. А для тих, кому складний мова оригінальної статті, на хабре є відмінний переклад.
З цього моменту описана модель розгалуження GitFlow, починає, що називається, розходитися по світу. Її беруть на озброєння багато команд. Автори пишуть багато статей про успішне її використанні. Вона отримує підтримку у більшості інструментів, які використовують розробники:
Git
Здається, що ідеальна модель. Бути може так воно і є, якщо у вас невелика команда, незмінний скоуп релізів, висока культура роботи з VCS. Тоді, дійсно, GitFlow може і задовольнить всі ваші потреби. Але, на жаль, описані умови підходять не всім командам і не всім проектам. До речі, знайти статті, в яких автори описували проблеми цієї моделі не так вже й просто, навіть в 2016 році. Але як ми всі знаємо, срібної кулі немає, а, значить, і в цій моделі все добре далеко не для всіх.
Читати далі →

Щоденні релізи — це не так вже страшно



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

Спочатку, коли я тільки прийшла в DataArt, слово «реліз» асоціювалося у мене з чимось страшним. Але, як виявилося, якщо процес роботи побудований правильно, релізи навіть кожен день — зовсім не страшно, а дуже навіть зручно.Щоб цього досягти, процес розробки у нашому проекті побудований на принципах безперервного постачання (continuous delivery) і безперервної інтеграції (continuous integration).

Що таке Continuous delivery і Сontinuous integration?


Continuous delivery або безперервна поставка ПО — набір практик і принципів, спрямованих на збирання, тестування і постачання ПО швидше і частіше. Безперервна постачання якісного коду спирається, у свою чергу, на безперервну інтеграцію.

Сontinuous integration, або безперервна інтеграція — це практика розробки ПЗ, яка полягає у виконанні частих автоматизованих збірок проекту для якнайшвидшого виявлення і вирішення інтеграційних проблем. Адже зрозуміло: якщо над різними частинами коду працюють кілька програмістів, при інтеграції цих частин виникає багато труднощів. Безперервна інтеграція допомагає впоратися з ними.

Читати далі →

Автоматизація workflow невеликої команди розробки (Частина 2)

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

У цій статті я спробую описати, як ми використовуємо в щоденній роботі всього колективу розробки.

Протягом 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. Навіть більше того, концептуально цей процес придуманий їй, а я вже зміг його технічно реалізувати і в деяких місцях вдосконалити.

Читати далі →

Система складання для великих модульних проектів

На сторінках нашого блогу ми вже писали про переваги організації репозиторію великого проекту способом, що передбачає можливість вилучення джерел в змінювану структуру робочої копії. Використання такого підходу укупі з потребами простого конфігурування, фрагментарною складання, підтримки декілька десятків ОС під широкий спектр апаратних платформ стали причиною розробки нами власної системи складання. Ця стаття розповідає про знайдених нами рішеннях, які можуть бути цікаві розробникам, сталкивающимися з труднощами підтримки інфраструктури великих проектів.



Читати далі →