Создание качественного ПО — непростой процесс. Во-первых, нужно решать бизнес-проблемы и писать качественный код. Однако, на этом сложности не заканчиваются: нужно еще удостовериться в том, что ваш код работает быстро, безопасно и надежно. Работа с кодом — это конвейер из множества этапов, таких как сборка, интеграция, тестирование, обеспечение безопасности, ревью, настройка и развертывание. На выполнение всех этих действий уходит много времени и сил.
Привет! Сегодня в нашем блоге мы проводим уже традиционную секцию вопросов и ответов Ask Me Anything. (До этого были АМА по бэкенду и по android-разработке). Продолжаем хорошую традицию. На этот раз речь пойдёт о разработке под iOS в целом и об особенностях приложения Авито в частности.
Как работается с приложением самого популярного сайта объявлений в России? Спросите у нас! Мы ответим на все комментарии первого уровня, которые появятся здесь до полудня 6 июня по московскому времени. Под катом я представляю семь моих коллег, которые будут с вами на связи, рассказываю немного об iOS-разработке в Авито и о возможных темах диалога.
Привет! Сегодня в нашем блоге мы проводим уже традиционную секцию вопросов и ответов Ask Me Anything. (До этого были АМА по бэкенду и по android-разработке). Продолжаем хорошую традицию. На этот раз речь пойдёт о разработке под iOS в целом и об особенностях приложения Авито в частности.
Как работается с приложением самого популярного сайта объявлений в России? Спросите у нас! Мы ответим на все комментарии первого уровня, которые появятся здесь до полудня 6 июня по московскому времени. Под катом я представляю семь моих коллег, которые будут с вами на связи, рассказываю немного об iOS-разработке в Авито и о возможных темах диалога.
В этой статье хочу рассказать о подходе к сборке Unity-проектов на android и ios через Gitlab на собственных сборщиках с macOS.
Я работаю в небольшой gamedev компании, и задача автоматизации сборки появилась из-за следующих проблем:
Представьте что в Роскосмосе решили собрать новую ракету не имея при этом чертежей и четкого понимания как ракета должна быть устроена. Отдельный завод занимается корпусом ракеты, отдельный выпускает двигатели, еще один — сопла. Главный менеджер Роскосмоса сказал что он доверяет профессионалам, и мастерски сделегировал всю работу заводам.
Через год все составные части доставляются в главный сборочный цех, и выясняется, что двигатель не входит в корпус, а сопла начинают плавиться даже при тестовых запусках двигателя.
Чтобы такой фигни не случалось, в реальных проектах всегда есть этап планирования и проектирования, на котором фиксируются спецификации того как части будут взаимодействовать между собой и какими характеристиками ни должны обладать.
При разработке ПО мы не можем себе позволить долгий этап проектирования, т.к. за это время потеряется бизнес-ценность того что мы пытаемся разработать — нас тупо обойдут конкуренты.
Поэтому команды, разрабатывающие составные части программы(модули) зачастую вынуждены работать не до конца понимая как их модуль будет взаимодействовать с остальными частями.
Как и в случае с ракетой, при попытке выпустить новый релиз приложения, разрабатываемого по частям несколькими командами, может выясниться что какие-то из модулей не совместимы.
В 1991 году Гради Буч, видимо, устал от такого безобразия, и предложил делать сборку всего проекта каждый день, чтобы выяснять несовместимости не в день релиза, а пораньше — и назвал этот подход Continuous Integration.
Читать полностью »
После того, как Ansible вошёл в нашу практику, количество кода на нём и, в частности, ролей стало расти очень быстро. Роли для бэка, фронта, прокси, баз данных, мониторинга, сбора логов и т. д. и т. п.—их количество насчитывает десятки. Часть из ролей специфична для определённого проекта, но многие решают общие задачи, ими хочется делиться между проектными командами, чтобы не создавать одно и то же решение дважды.
Вместе с большим количеством кода появляется и старая, знакомая проблема: страх изменений. Люди не желают вносить изменения в «чужую» роль, опасаясь испортить её, вместо этого создают собственную копию. Рефакторинг кода не производится, если код прямо сейчас не находится в фокусе разработки, из-за опасения, что внесённые проблемы могут быть обнаружены спустя слишком большое время. Итог: плохой код растёт как снежный ком.
Сейчас публикуется много статей и докладов про конкретные технологии в DevOps: Docker, Kubernetes, Ansible… Я же хочу поговорить про построение процессов и про то, как мы в Wrike за два с половиной года эволюционировали от релизной системы для 15 фронтенд-разработчиков до почти 60-ти, и 2-3 деплоев в день.
Эта статья — про те уроки, которые мы на этом пути решили. Статья основана на моем докладе для DevOps митапа в Wrike Tech Club. Если некогда читать, есть видеозапись презентации. Читатели, добро пожаловать под кат.
Читать полностью »
Привет!
На прошлой неделе мы выпустили новую версию нашего CI и CD сервера: TeamCity 2017.2! Как вы, наверняка, поняли из заголовка, она полна не только новой функциональностью, но и преподнесет приятный сюрприз тем, кто пользуется бесплатной (Professional) версией. Но обо всем по порядку.
Прежде всего, список всех улучшений, как всегда, очень внушительный – ознакомьтесь с ним после прочтения этого поста, если захотите подробностей. Здесь же мы остановимся на самых “вкусных” фичах последнего релиза.
После обновления до версии 2017.2 все пользователи TeamCity Professional будут приятно удивлены — вместо стандартных 20 билд-конфигураций TeamCity теперь предоставляет 100! Это доступно абсолютно бесплатно каждому пользователю версии 2017.2. Никаких подводных камней. Для не знакомых с терминологией, билд-конфигурация (build configuration) в TeamCity – это то же самое, что и job в терминах Jenkins.
Читать полностью »
В мире современных веб-технологий все стремительно развивается и меняется. Пару лет назад совершенно нормальным было по запросу клиента рендерить DOM структуру на сервере (например, при помощи PHP) и отдавать уже полностью сформированную страницу. Сейчас все чаще появляются сайты c полным отделением фронтенда (Angular, React, Vue.js...) от бэкенда (некие API эндпоинты), где на фронтенде почти весь контент формируется посредством скриптов, а сервер отдает только данные по запросу. Тут можно было бы упомянуть SSR (Server Side Rendering), но не об этом данное произведение.
В любые времена перед разработчиками и владельцами сайтов стояла непростая задача: доставить контент как можно быстрее, как можно большему количеству клиентов. Одно из самых правильных решений — использовать CDN (Content Delivery Network) для раздачи статичных файлов. В случае с динамическим рендером страниц на сервере мы должны были ограничиваться небольшим списком объектов, которые можно было разместить в CDN: таблицы стилей, файлы скриптов, изображения. Однако, фронтенд, написанный на Angular (React, Vue.js...), статичен целиком, включая индексную страницу. Вот тут и возникает мысль: а почему бы не организовать раздачу через CDN всего фронтенда?
В данной статье пойдет речь о настройке комплексного решения для разработки, контроля версий, автоматической сборки и доставки статического сайта с использованием Gitlab CI, Amazon S3 и Amazon CloudFront. Также речь пойдет о настройке сопутствующих вещей: git, безопасное соединение по протоколу HTTPS, доменная почта, DNS хостинг, бэкенд сервер…
Если вас заинтересовала эта тема, добро пожаловать под кат.
Осторожно! Много скриншотов.
Читать полностью »
В этой статье я расскажу, как можно оперативно настроить автоматическое стягивание нового кода на тестовый сервер вашего laravel-приложения, автозапуск тестов и оповещение о результате в соответствующий корпоративный чат. А также отлавливание новых ошибок в laravel.log
Читать полностью »
