Подробная статья по докладу: https://habrahabr.ru/company/mobileup/blog/314838/
Team Lead MobileUp Константин Цховребов выступил в Новосибирске на IT-конференций DevFest.
Поделиться азами гибкой простой и функциональной навигации по экранам при использовании MVP в Android. Рассказал, как сделать код навигации чистым и lifecycle-безопасным, а любую, даже самую навороченную цепочку переходов по экранам – делом пары строк.
Подробная статья по докладу: https://habrahabr.ru/company/mobileup/blog/314838/
Team Lead MobileUp Константин Цховребов выступил в Новосибирске на IT-конференций DevFest.
Поделиться азами гибкой простой и функциональной навигации по экранам при использовании MVP в Android. Рассказал, как сделать код навигации чистым и lifecycle-безопасным, а любую, даже самую навороченную цепочку переходов по экранам – делом пары строк.
Александр Чистяков - Большой веб-проект: развитие, рост, проблемы, решения с ...HappyDev
Доклад о проблемах в строительстве и развитии большого веб-проекта. История развития высоконагруженного сайта глазами работника эксплуатационной команды.
Как говорил Чебурашка: "Мы строили-строили и, наконец, построили". В IT фаза "строили-строили" далеко не всегда переходит в "и, наконец", кроме того, вместо "построили" обычно наступает "версия 2.0", где 2.0 может быть любым числом.
Докладчик находился на стройке между версиями 1.0 и 2.0, помогал таскать кирпичи, мешать раствор и караулил территорию по ночам. В свободное от этих обязанностей время он задавался вопросами "как мы строили?", "почему мы строили?", "зачем мы взяли гвозди, а не нитки", а также "почему в версии 2.0 получился высоконагруженный сайт, а не космический корабль". Именно история развития высоконагруженного сайта глазами работника эксплуатационной команды и составляет основу доклада.
Поскольку история еще не закончена, слушатели познакомятся и с ее новейшими главами, в том числе будут затронуты такие важные темы, как "как выжить в современном мире адепту Церкви Графиков" и "выпуск major release в пятницу вечером - плюсы и минусы".
Как не подавиться большим старым проектом. Юрий Минаев ➠ CoreHard Autumn 2019corehard_by
Мир изменился. То, что работало раньше, не то чтобы перестало работать, но стало недостаточным. Парное программирование, обзоры кода, юнит-тесты по-прежнему важны и необходимы, но они уже не могут обеспечить должного уровня качества и надёжности С++ проектов. Многие проекты выросли в сотни раз. Рост происходил постепенно, и еще не все поняли, что произошло. Любой большой старый проект состоит из разнородных слоёв (геологических отложений) и, самое главное, уже никто не знает, как это всё работает. Пришло время инструментов и методологий, помогающих сохранять качество и целостность кода: DevSecOps, статический анализ, динамический анализ, платформы измерения качества.
TК°Conf. Микросервисы и Docker. Глеб Паньшин.TKConf
Когда вы пытаетесь следовать гибким методологиям, создавать небольшие автономные команды, микросервисы в вашем проекте появляются естественным путем. Или нет. Обязательно поговорим о "Монолит vs. Микросервисы". И хотя эти маленькие трудяги помогают вам scale и достигать agility они неплохо добавляют вам проблем с доставкой и разработкой.
В заключении попробую ответить на вопрос как деплоить 5 или 50 микросервисов? Не знаю, но давайте попробуем Docker.
Vladimir Obrizan "Ecosystem for reliable Python programming"Fwdays
With the increasing complexity of applications, the likelihood of software errors increases significantly. There are about ten tools in the Python programming ecosystem that can significantly reduce the risk of errors: unittest, pytest, unittest.mock, Freeze Gun, Webtest, Factory Boy, tox, retrying, Cosmic Ray, BitBucket Pipelines.
In the talk we will discuss the advantages and disadvantages of these technologies, as well as recommendations on what stage of development to apply.
Сергей Сергеев "Менеджмент кода, или Почему SCM"Yandex
В Яндексе не только пишут код, но ещё и запускают его в виде сервисов. Из доклада вы узнаете, как мы обслуживаем наш код, какие процессы выстраиваем для правильного соблюдения релизного цикла и как нам в этом помогает Git и GitHub.
Не хватает, скажем, человеку рук - он создает себе дубля, безмозглого, безответственного, только и умеющего что паять контакты, или таскать тяжести, или писать под диктовку, но зато уж умеющего это делать хорошо.
Аркадий и Борис Стругацкие
Статья представляет собой введение в параллельные программы для начинающих. Статья была опубликована в журнале "Мир ПК" (http://www.viva64.com/go.php?url=429).
The document discusses changes made to the code structure and architecture of Magento. Key changes include extracting the Magento framework, splitting modules, eliminating code pools, renaming Mage to Magento, and adopting a dependency injection pattern. Unit testing and configuration via XML files are also mentioned. The changes aim to improve the code structure through separation of concerns and dependency injection.
Александр Чистяков - Большой веб-проект: развитие, рост, проблемы, решения с ...HappyDev
Доклад о проблемах в строительстве и развитии большого веб-проекта. История развития высоконагруженного сайта глазами работника эксплуатационной команды.
Как говорил Чебурашка: "Мы строили-строили и, наконец, построили". В IT фаза "строили-строили" далеко не всегда переходит в "и, наконец", кроме того, вместо "построили" обычно наступает "версия 2.0", где 2.0 может быть любым числом.
Докладчик находился на стройке между версиями 1.0 и 2.0, помогал таскать кирпичи, мешать раствор и караулил территорию по ночам. В свободное от этих обязанностей время он задавался вопросами "как мы строили?", "почему мы строили?", "зачем мы взяли гвозди, а не нитки", а также "почему в версии 2.0 получился высоконагруженный сайт, а не космический корабль". Именно история развития высоконагруженного сайта глазами работника эксплуатационной команды и составляет основу доклада.
Поскольку история еще не закончена, слушатели познакомятся и с ее новейшими главами, в том числе будут затронуты такие важные темы, как "как выжить в современном мире адепту Церкви Графиков" и "выпуск major release в пятницу вечером - плюсы и минусы".
Как не подавиться большим старым проектом. Юрий Минаев ➠ CoreHard Autumn 2019corehard_by
Мир изменился. То, что работало раньше, не то чтобы перестало работать, но стало недостаточным. Парное программирование, обзоры кода, юнит-тесты по-прежнему важны и необходимы, но они уже не могут обеспечить должного уровня качества и надёжности С++ проектов. Многие проекты выросли в сотни раз. Рост происходил постепенно, и еще не все поняли, что произошло. Любой большой старый проект состоит из разнородных слоёв (геологических отложений) и, самое главное, уже никто не знает, как это всё работает. Пришло время инструментов и методологий, помогающих сохранять качество и целостность кода: DevSecOps, статический анализ, динамический анализ, платформы измерения качества.
TК°Conf. Микросервисы и Docker. Глеб Паньшин.TKConf
Когда вы пытаетесь следовать гибким методологиям, создавать небольшие автономные команды, микросервисы в вашем проекте появляются естественным путем. Или нет. Обязательно поговорим о "Монолит vs. Микросервисы". И хотя эти маленькие трудяги помогают вам scale и достигать agility они неплохо добавляют вам проблем с доставкой и разработкой.
В заключении попробую ответить на вопрос как деплоить 5 или 50 микросервисов? Не знаю, но давайте попробуем Docker.
Vladimir Obrizan "Ecosystem for reliable Python programming"Fwdays
With the increasing complexity of applications, the likelihood of software errors increases significantly. There are about ten tools in the Python programming ecosystem that can significantly reduce the risk of errors: unittest, pytest, unittest.mock, Freeze Gun, Webtest, Factory Boy, tox, retrying, Cosmic Ray, BitBucket Pipelines.
In the talk we will discuss the advantages and disadvantages of these technologies, as well as recommendations on what stage of development to apply.
Сергей Сергеев "Менеджмент кода, или Почему SCM"Yandex
В Яндексе не только пишут код, но ещё и запускают его в виде сервисов. Из доклада вы узнаете, как мы обслуживаем наш код, какие процессы выстраиваем для правильного соблюдения релизного цикла и как нам в этом помогает Git и GitHub.
Не хватает, скажем, человеку рук - он создает себе дубля, безмозглого, безответственного, только и умеющего что паять контакты, или таскать тяжести, или писать под диктовку, но зато уж умеющего это делать хорошо.
Аркадий и Борис Стругацкие
Статья представляет собой введение в параллельные программы для начинающих. Статья была опубликована в журнале "Мир ПК" (http://www.viva64.com/go.php?url=429).
The document discusses changes made to the code structure and architecture of Magento. Key changes include extracting the Magento framework, splitting modules, eliminating code pools, renaming Mage to Magento, and adopting a dependency injection pattern. Unit testing and configuration via XML files are also mentioned. The changes aim to improve the code structure through separation of concerns and dependency injection.
The document discusses using Composer and modules to better organize Magento projects. It recommends:
- Using Composer to install Magento core and modules separately from the project codebase.
- Treating modules as independent, reusable components with their own versioning and maintenance.
- Allowing multiple teams to collaborate on developing the same module for different projects.
- Managing module versions and dependencies flexibly between projects through Composer.
Database automated deployment and versioning ...for smart peopleAlexey Diyan
There are a lot of tools which allows us automate deployment process for databases.
Those tools could be divided into two big groups:
#1. Tools that uses general purpose language (Ruby, C#, Java, Python) for writing migration scripts.
#2. Tools that uses SQL language for writing migration scripts.
First group of tools gives for developers productive gain but leaves database administrator completely out of development process which is really bad idea.
Second set of tools requires a lot of additional work - every single change should be written as separate database patch. This slows down our work => make it more expensive.
Oblivious solution is to create the third set of tools... or at least just one which would be friendly to both DBAs and DEVs.
What about auditors? They should be happy too!
13 октября, DEV {web} - конференция о Highload веб-разработке. "Управление ок...IT-Portfolio
13 октября, DEV {web} - конференция о Highload веб-разработке. "Управление окружениями в сложном проекте: Chef и другие", Александр Чистяков (ведущий разработчик Cezurity).
Аннотация
Облачный антивирус, который мы делаем в партнерстве с vk.com, отличается от типичного веб-проекта наличием большого числа специализированных и не очень специализированных подсистем. Это ставит перед отделом эксплуатации принципиально новые вызовы: нужно не только уметь реагировать на случайные сбои и предсказывать неслучайные, но и просто помнить где что лежит и какую задачу выполняет. О том, как мы отвечаем на эти вызовы в компании Cezurity - мой доклад.
Биография
Докладчик - узкий специалист широкого профиля, относит себя к виду, называемому в современной англоязычной литературе термином "DevOps". Любит принимать участие в создании сложных систем и постоянно это делает. Никогда не работал в Яндексе, компенсировав это работой в Mail.Ru и некоторых других местах.
Презентация рассказывает о том, кто такие девопс инженеры, какие проблемы они решают, когда команда разработчиков может обойтись без них и какие инструменты для этого использовать.
«Continuous Integration — A to Z или Непрерывная интеграция — кто всё сломал?»FDConf
Доклад о том, зачем нужен CI, как он интегрируется в процесс разработки. В докладе есть небольшое демо о весьма известном cloud-based CI сервисе Travis-CI. В процессе демо будет «поломан» билд и затем сразу же починен. Весьма показательно в том плане, что это доказывает простоту всей технологии.
Вместе с Алексеем Ашурком мы расскажем о том, как проект «Фламп» релизится по 2n раз в неделю и комфортно себя при этом чувствует:
— Ветки - это хорошо или о переходе с SVN на Git.
— Чем плоха «классическая» модель релизов.
— Что такое модель пофичных релизов, в чём её плюсы и минусы.
— Почему она подходит для веб-сервисов.
— Как идти в ногу со временем или частые деплои.
— Как ловить ошибки и минимизировать их число.
Видео доклада: http://devday.2gis.ru/report/15
CONTINUOUS INTEGRATION ДЛЯ ЧАЙНИКОВ ВМЕСТЕ С TEAMCITYPavel Tsukanov
то такое "Непрерывная Интеграция", зачем она нужна и с чем ее едят? Правда ли, что она нужна только для тестировщиков? На все эти вопросы мы постараемся найти ответы в ходе выступления Щербакова Ильи на нашей следующей юзер-группе.
Проблемы и пути их решения при командной разработке проектовАгентство AlterEGO
– Кому нужна командная разработка?
– Что делать в команде?
– Решение реальных задач, распределение ответственности
– Командная разработка на 1С-Битрикс
– Миграции БД
– Проблемы и пути их решения
Yurii Hryhoriev "Php storm tips&tricks"Magento Dev
PhpStorm: Tips & Tricks
• Scopes: фокусируемся на важном
• Улучшеная инспекция: статический анализ в реальном времени
• Внешние утилиты и быстрые списки
• CLI утилиты. bin/magento становится ближе
The document discusses Magento 2, an e-commerce platform. It highlights that Magento 2 aims to have less code in modules, true modularity, and adoption of Composer and Require.js to be simpler. To be faster, it focuses on full page caching, Varnish, and new indexing processes. To offer more features, it includes a REST API, support for LESS and jQuery, and unit tests. The document also discusses dependencies and services in Magento 2, and concludes with a demo and Q&A section.
The document discusses Magento 2's front-end architecture and how to create themes. It covers Magento 2's goals of improving performance, making upgrades easier, and using high-quality code. It also discusses how consumers use multiple devices for purchases and how to get started with Magento 2 on GitHub. The document then provides instructions on how to create a theme by defining its configuration file and structure, working with CSS by extending and overriding styles, manipulating layout using XML, and overriding templates.
Top 5 magento secure coding best practices Alex ZarichnyiMagento Dev
This document discusses the top 5 Magento secure coding best practices:
1. Validate all input as strictly as possible using whitelist validation and built-in validators.
2. Use parameterized queries to prevent SQL injection instead of concatenating variables into queries.
3. Escape all user input on both the frontend and backend to prevent XSS attacks.
4. Use CSRF tokens on forms to prevent cross-site request forgery attacks.
5. Add security headers to responses to enable protections like XSS filtering and preventing clickjacking.
The document discusses importing a large number of entities (~1 million) into an EAV (Entity-Attribute-Value) database model. Standard row-by-row imports do not scale well for large amounts of data due to validation overhead. The proposed solution is to use bulk loading via MySQL's "LOAD DATA INFILE" command to minimize validation and import the data in bulk. This improves performance significantly but reduces data integrity checks. Some techniques like pre-processing and post-processing are discussed to balance integrity and performance for unpredictable data sources. Test results show substantial speed improvements for bulk loading large amounts of data.
The document discusses Gearman, an open source software framework for distributing tasks across multiple machines. It describes how Gearman allows for asynchronous task processing by queuing jobs on a central job server that workers on other machines can pick up. The key advantages of Gearman include high performance, scalability, load balancing, and the ability to perform tasks asynchronously and in parallel. The document also provides code examples of how to use the Gearman PHP client and worker APIs to process jobs. It discusses challenges like handling task failures and explores ways to retry failed tasks, such as by scheduling suspended jobs to be executed again at increasing time intervals.
2. Мы рассмотрим вопрос контроля версий в проекте.
Поговорим в контексте двух систем - GIT (стильно, модно,
моложёжно) и SVN - это, оказывается, не менее популярная, а
даже и более распространённая система контроля версий (по
данным каталога свободного ПО ohloh.net). Мне довелось
поработать с обеими системами, вначале с SVN, за тем и с GIT,
включая миграцию проектов и околопроектных сервисов на
GIT.
Под околопроектными сервисами имеются ввиду
различные пре- и посткоммит хуки и системы развёртывания
приложений. На основе этого опыта и мнения разработчиков
нашей компании Smile я и хочу сравнить эти системы и
узнать, правду ли гласит информация с сайта GIT, всяко разно
расхваливая его и называя SVN пережитком прошлого.
3. Использование систем контроля версий
GIT и SVN в проектах с открытым исходным
кодом в каталоге ohloh.net
50 000
100 000
150 000
200 000
250 000
300 000
350 000
Авг'10 Май'11 Фев'12 Июнь'12 Окт'13 Июль'14
GIT SVN
4. Цифры не лгут, SVN всегда был на шаг впереди GITа, а в
последний год даже начал немного вырываться вперёд. А это
значит, что SVN совсем не умер, он живее всех живых!
Но, по некоторым причинам, о которых мы сегодня и
поговорим, молодая часть Интернетов считает, что SVN
одного возраста с мамонтами, работает непростительно
медленно, криво и совсем не мерджит. Ах да, чуть не забыл, и
создаёт везде папки .svn
5. Хозяйке на заметку.
Я просто оставлю это здесь.
Ohloh.net, http://www.ohloh.net
Бесплатный публичный каталог программ с открытым
исходным кодом, построен по принципу вики. По состоянию на
июль 2014 года там зарегистрировано 664,816 проектов. Это
не хостинг проектов, а служба, позволяющая анализировать эти
проекты.
!
Wayback Machine, https://archive.org/
Архив Интернета - обеспечивает долгосрочное архивирование
собранного материала и бесплатный доступ к своим базам
данных для широкой публики. По состоянию на октябрь 2012
года размер Архива — 10 петабайт. По состоянию на июнь
2014 года он содержит 415 миллиардов веб-страниц
7. Начнём с того, что системы разные, и построены они по
разным принципам. GIT - это распределённая система, а SVN -
централизованная.
Это важное различие накладывает некоторые
ограничения на использование систем, а также заранее
предполагает, что разработчик будет использовать
правильный, и что самое главное, подходящий под тип
системы подход в работе с ней.
Сегодня я постараюсь немного приоткрыть
сомнительную завесу унылости SVN и показать, что SVN ни
чем не хуже GITа, а в некоторых местах - даже лучше, потому
что он проще, а это значит, что шансы "выстрелить себе в
ногу" гораздо меньше.
8. Централизованные (Centralized) и
распределённые (Distributed) системы
контроля версий
+ простота команд
+ сквозная нумерация коммитов
+ удобное линейное перемещение по
монолитной неизменяемой* истории
+ простой контроль доступа к элементам
репозитория
+ частичный чекаут/экспорт
- очень часто нужна связь с
центральным сервером
- неприлично медленный upstream
- нельзя локально просмотреть историю
и создать ветку*
- много наговаривают в Интернетах из-
за убогости версий до 1.5 (Июнь’08) и,
частично, до 1.7 (Окт’11)
+ высокая скорость upstream
+ просмотр истории локально
+ не нужно частое подключение к
серверу
+ располагает к созданию локальных
веток
- бóльший размер оверхеда из-за всей
истории в локальном репозитории
- недостаточный контроль доступа к
элементам репозитория
- нелепая невозможность хранить
пустые папки
- хеш-нумерация коммитов
- возможность перезаписи истории
(rebase, squash…)
9. Централизованные системы подразумевают наличие
центрального сервера, на котором всегда хранится последняя
версия код проекта. Каждый разработчик для выполнения
большинства операций с репозиторием должен иметь соединение
с сервером. Это основное неудобство таких систем как SVN - связь
с сервером при выполнении коммитов или просмотра истории.
Но в современном мире это не доставляет достаточно много
хлопот, и это недостаточный повод чтобы не работать с такой
системой. Центральный репозиторий, с другой стороны, имеет
некоторые плюсы - сквозная нумерация коммитов, каждый из
которых включает себя полное и целостное состояние
репозитория со всеми ветками.
Это позволяет легко путешествовать по истории проекта, не
сложнее, чем перематывать плёнку в кассете - ты всегда знаешь, что
находишься в контексте определённого состояния и ни одна душа
(ну, кроме админа с root доступом к центральному репозиторию)
эту историю изменить не в состоянии.
10. А что мы имеем в случае распределённой системы? Опять же, в
большинстве случаев нам нужен центральный репозиторий для
синхронизации всех изменений между разработчиками (удивительно,
система распределённая, а репозиторий всё-таки лучше иметь, чтобы
паровозиком друг за дружкой не ходить).
Правда плюсом является то, что нам этот сервер нужен только в
моменты синхронизации изменений, для просмотра истории нам
достаточно локального репозитория.
Всего репозитория. Полностью. Со всей его богатой историей.
И всеми удалёнными ветками тоже.
GIT всё запоминает. И при клонировании репозитория нам всё
это приходит. Кто-то мне говорил, что SVN даёт много оверхеда. До
GITа ей ой как далеко.
Ну а что же с контролем? Как защитить какие-то части проекта
от изменений, например? В SVN - проще простого. С точностью до
файла. А в GIT? Можно лишь частично, нужно писать server-side
hook, который будет проверять что там в коммите меняется и
реджектить его, если лезем туда, куда не следует.
11. Но зато скорость записи в удалённый репозиторий у GIT
в разы и разы больше. Я пробовал делать чекаут второй
маженты (в моём докладе должно было быть что-то про
вторую маженту - вот оно), чекаут второй маженты из гита и
свн занимал приблизительно одинаковое время - т.е. результат
разнился не более чем на 20%.
Но вот push всего проекта в чистый репозиторий… В GIT
- соизмеримо с checkout - в SVN - я не дождался. Терпение
кончилось на каком-то модуле в районе буквы D.
Это действительно крайне неприятно и долго в SVN -
сделать коммит кучи мелких файлов.
Вот первое адекватное правило при выборе системы
контроля версий - если нужно часто коммитить много
файлов - используйте GIT - это будет быстрее.
12. Про SVN вообще многие отзываются негативно и не хотят
на нём работать, по нескольким причинам - первая - не
рекомендуют старшие товарищи, столкнувшиеся с SVN и по тем
или иным причинам не взлюбившие эту систему.
Если они работали со старым SVN’ом до версии 1.7 или даже
до 1.5 - то я их понимаю - там проблем было гораздо больше.
Но было это от 3-х до 6-ти лет назад, а детская травма всё не
даёт покоя.
Отсюда еще одно правило - если проект на SVN - то
работайте с версией 1.7. В ней уже решены многие проблемы и
замазаны слабые места. Уже только одна папка .svn в корне
проекта! Чекаут проекта стал еще быстрее! А вообще, чего
только стоит возможность частичного чекаута и экспорта
ресурсов из репозитория? Попробуйте подправить часть
большого проекта в ГИТ - придётся выкачивать весь репозиторий
целиком! Даже самая мелкая правка в походных условиях
потребует от нас наличия полного репозитория проекта.
13. SVN и GIT: первоначальная настройка
# Настройка идентификации
git:$ git config --global user.name "Volodymyr Fesko"
git:$ git config --global user.email vofes@smile.fr
!
# Правильная обработка line-endings в репозитории
git:$ git config core.autocrlf native
!
# Игнор мониторинга разрешений на файлы
# Для изменения разрешений используем git update-index --chmod=+x
foo.bar
git:$ git config core.filemode false
!
# Используем .gitattributes вместе с .gitignore для настройки
репозитория
!
# Правильная обработка line-endings в репозитории
# svn:eol-style=native в auto-props
# http://www.mediawiki.org/wiki/Subversion/auto-props
14. SVN и GIT workflow: новый репозиторий
# Создаём репозиторий
svn:$ svnadmin create /home/me/svn-repo
!
# Импортируем файлы проекта
svn:$ svn import /home/me/project-files
file:///home/me/svn-repo/trunk -m "Initial commit"
svn:$ svn co file:///home/me/svn-repo /home/me/project
!
# Создаём репозиторий
git:$ cd /home/me/project-files
git:$ git init
!
# Импортируем файлы проекта
git:$ git add .
git:$ git commit -m "Initial commit"
15. В SVN самое главное при работе с ветками - это правильно их
создавать. Вообще понятие веток в SVN немного расплывчато и
время от времени можно так сказать выстрелить себе в ногу.
Ветки создаются той же командой, что и обычное копирование
файлов в репозитории с последующим коммитом - командой copy.
Но есть большая, принципиальная разница в том, какие
параметры передавать этой команде.
В SVN ветки создаются всегда на сервере, причём одинаково
быстро вне зависимости от размера репозитория - здесь они по
скорости не проигрывают веткам в GIT.
Для создания ветки мы должны сказать SVN, чтобы она
выполнила копирования на сервере, а не внутри рабочей копии.
Для этот перед папкой, из котороый мы создаём ветку (а это
не обязательно должен быть корень транка, это может быть любое
поддерево), перед этим путём нужно использовать либо полный
путь к репозиторию https://, например, или же простой символ -
крышечку.
16. При переключении веток - то же самое, либо полный адрес,
либо крышечка. Время от времени подмешиваем в нашу ветку
изменения из транка, а затем, когда уже всё готово, сливаем
изменения из ветки в транк с ключем reintegrate. Это
обязательное условие обратного объединения ветки feature с
транком, т.к. начиная с версии 1.5 в SVN появился трекинг
мерджей, который по сути просто запоминает какие ревизии
куда были смерджены. До версии 1.5 нам приходилось явно
указывать набор ревизий для мерджа веток, чтобы не сливать
одни и те же изменения по два раза. Теперь SVN трекает это
самостоятельно.
Если мы мерджим транк в нашу feature ветку, при этом
разрешая конфликты, то при обратном мердже в транк мы
потеряем эти разрешения, т.к. мердж с разрешёнными
конфликтами - это отдельный коммит и он будет записан в
mergeinfo и пропущен при объединений ветки feature и транка.
17. SVN и GIT workflow: ветки
# Создаём ветку
svn:$ svn cp ^/trunk ^/branches/feature-1
!
# Переключаемся в ветку
svn:$ svn sw ^/branches/feature-1
!
# Подтягиваем изменения из транка в свою ветку - время от времени
# А также непосредственно перед интеграцией ветки обратно в транк
svn:$ svn merge ^/trunk
!
# Мерджим ветку обратно в транк. КОГДА УЖЕ ВСЁ В НЕЙ ГОТОВО! После
этого работать в feature-1 НЕЛЬЗЯ. Только если её удалить и заново
отпочковать от транка - иначе потеряете всю работу по разрешению
конфликтов при мердже в транк
svn:$ svn sw ^/trunk
svn:$ svn merge --reintegrate ^/branches/feature-1
svn:$ svn delete ^/branches/feature-1
!
# P.S. Создать ветку на сервере, константа по времени - правильно
svn cp ^/trunk ^/branches/feature-1
# Скопировать содержимое и закоммитить - долго, неправильно
svn cp trunk branches/feature-1
18. SVN и GIT workflow: ветки
# Создаём ветку и переключаемся в неё
git:$ git checkout -b feature-1
!
# Подтягиваем изменения из master в свою ветку - время от времени
# А также непосредственно перед интеграцией ветки обратно в master
# Rebase делаем только для локальных веток. После push на origin -
только merge, чтобы коммиты не менялись
git:$ git rebase master
git:$ git merge master
!
# Мерджим ветку обратно в master
git:$ git checkout master
git:$ git merge feature-1
!
# Push изменений
git:$ git push origin master
19. Самым слабым место в GIT я считаю возможность
переписывать историю, делая rebase или sqaush коммитов.
Этим можно пользоваться в локальном репозитории, но
никак не в удалённом - если с вами на проекте работают еще
разработчики, то после пуша изменений ни в коем случае не
нужно делать rebase, т.к. это изменит все коммиты вашей
ветки после точки её отпочкования от основной и, если кто-
то их уже использовал как родительские или изменил их (не
дай Бог), то мы рискуем нарваться на сложности, которых
можно было просто избежать, потеряем лишнее время.
Не бойтесь, что мердж создаст вам лишний коммит, а
история не будет красивой и линейной - я не припомню
случая, когда более красивая история с чем-то помогла или
выручила в какой-то проблеме.
20. Кроме самого воркфлоу эти системы контроля версий
имеют еще две замечательные возможности первая - это пре-
и пост-action хуки.
Это простые скрипты, которые выполняются системой
контроля версий до и после действий типа коммита.
На пре-коммит хуки обычно вешаются код снифферы и
другие тесты, а на пост- интеграция с багртекерами,
непрерывная интеграция и уведомления.
Кучу всего можно поместить в хуки, вплоть до проверки
формата коммит сообщения и поиска в нём номера тикета в
багтрекере.
Это простые баш скрипты, которые запускаются
системой в нужные моменты.
21. SVN и GIT: хуки
(перечислены шаблоны и примеры)
# Хуки - это скрипты в папке hooks, делятся на pre- и post-action
# SVN
/home/me/svn-repo/hooks:
post-commit.tmpl
post-lock.tmpl
post-revprop-change.tmpl
post-unlock.tmpl
pre-commit.tmpl
pre-lock.tmpl
pre-revprop-change.tmpl
pre-unlock.tmpl
start-commit.tmpl
!
# GIT
/home/me/project-files/.git/hooks:
applypatch-msg.sample
commit-msg.sample
post-update.sample
pre-applypatch.sample
pre-commit.sample
pre-push.sample
pre-rebase.sample
prepare-commit-msg.sample
update.sample
22. И вторая классная штука - это внешние компоненты -
submodules в терминах GIT и externals в SVN. Это возможность
собрать наш проект из отдельных кирпичиков, переиспользовать
код модулей из других репозиториев - в общем, очень клёвая
фича.
В SVN она проста до безобразия, а вот в GIT есть нюансы,
особенно если мы не хотим интегрировать внешний репозиторий
целиком, а только по частям или одну подпапку сюда, одну туда.
В SVN это работает через свойства текущей папки
svn:externals при помощи svn:propset. Указываем имя подпапки, в
которую необходимо выдернуть внешний ресурс, делаем svn up - и
всё, внешний код уже у нас. В GIT у нас два варианта - submodules
и subtree merge. Сабмодули штука неповоротливая - целый
внешний репозиторий включаем в проект, нет возможности взять
лишь какую-то его папку. С сабтри мерджем чуть лучше ситуация,
и обновляется он сам, но в настройке посложнее будет.
Опять же в ГИТе всё сложнее, чем должно быть.
23. SVN и GIT: внешние компоненты
# svn:externals - чрезвычайно просто
svn:$ svn propset svn:externals 'foobar http://repo.url/tags/1.0' .
svn:$ svn up
Updating '.':
!
Fetching external item into 'foobar':
A foobar/class.php
...
!
# GIT
# Вариант 1: subtree merge
https://help.github.com/articles/working-with-subtree-merge
- сложнее, но можно использовать компоненты репозитория
!
# Вариант 2: submodules
git:$ submodule add git://github.com/chneukirchen/rack.git foobar
- проще, но берём репозиторий целиком
- нужно обновлять вручную и клонировать с --recursive
!
http://git-scm.com/book/en/Git-Tools-Submodules
24. Благодаря множеству возможностей система может как
проявить свои сильные стороны, так и сработать нам во вред.
Надеюсь, что ярые противники SVN немного переосмыслят своё
отношение к надёжной и зарекомендовавшей себя системе и уже
более обоснованно будут подходить к своим рекомендациям.
Да, кстати, в крайнем случае, например, при плохом коннекте,
при помощи утилиты svnsync можно создать локальную полную
копию репозитория, поработать с ней и сделать патч, который в
итоге накатить на настоящий репозиторий при первой же
возможности.
В общем, кто хочет, тот ищет возможности, кто не хочет -
ищет причины. Нам всем как современным разработчикам
необходимо пробовать на своей шкуре все возможные
инструменты и решения. GIT хорошая система и может заменить
SVN, но происходить это должно не потому, что "мне сказали,
что GIT лучше", мы должны сами понимать все эти плюсы и
минусы.