Приветствую вас, коллеги! Сегодня утром гитхаб опубликовал подробную статью о свежевышедшой версии git. Забрать ее, как обычно, можно на официальном сайте, а под катом — краткий перевод что нового и интересного: push-to-deploy, ручное управление параметрами SSH, способ предотвратить зависание cron скриптов с клиентом git и многое другое.
Кто из вас вообще слышал, что такое StarTeam? Думаю мало кто, в прочем как и я пару месяцев назад.
Я до моего текущего места работы вообще не слышал о таком продукте компании Borland. Если спросить у гугла, то окажется, что данный продукт до сих пор существует и даже развивается, но как вы все догадались, речь пойдёт далеко не о последней версии и даже не о предпоследней. У меня версия 5.3, которая была разработана где-то в 2003 году, а установлена и запущена в оборот здесь в 2004 году. И вот почти 11 лет она работала и решала свои задачи.
Обнаружена новая критическая уязвимость CVE-2014-9390 в Git, позволяющая выполнить произвольные команды на клиенте.
Суть уязвимости заключается в возможности совершить коммит в .Git/config, что равносильно служебному пути .git/config на регистронезависимых файловых системах. Это дает возможность инициировать запуск произвольных команд на клиенте. В общем случае уязвимости подвержены рабочие станции на Windows и Mac OS X, Linux-системы будут подвержены в случае использования регистронезависимых файловых систем.
Всю рутину, которую можно отдать роботам, нужно отдать роботам. Большие системы без этого невозможны. В разработке и тестировании очень много похожих задач, которые не требуют высокой квалификации, но отнимают много времени. Человек, который умеет обеспечить разработку, тестирование и деплой – это редкий специалист и его на количество страничек никак не масштабируешь.
В Яндексе тестировщику невозможно без автоматизации. Мы даже развиваем экспериментального робота, который способен брать на себя функциональное тестирование. В какой-то момент мы поняли, что не так много людей осознают, сколько сейчас есть возможностей работать не 12 часов, а головой. Собрав весь свой опыт в тестировании и деплое, мы открыли в питерском офисе Яндекса Школу автоматизации процессов разработки. У нас получилась школа, где каждый, кто пишет код, может получить базовый набор знаний о том, как собрать, запустить и поддерживать сервис в продакшене так, чтобы это стоило недорого.
Курс открывает моя лекция о том, зачем вообще автоматизировать процесс разработки. Из нее вы получите представление о то, что будут рассказывать мои коллеги.
Сейчас занятия закончились, и мы, как и обещали, выкладываем записи лекций, которые перемежаются с мастер-классами, для всех желающих. Понятно, что наш опыт и знания – не 42, но мы надеемся, что они принесут вам пользу.
Сразу скажу, что целевая аудитория поста и события: руководители в разработке на C#/.Net, в том числе тимлидеры и менеджеры проектов. И те, кто планирует переходить на руководящую позицию.
Я поделюсь логикой формирования программы второго дня конференции Go#.
Мы взяли темы, которыми должен владеть человек на руководящей позиции в разработке. При этом конкретная имплементация этих знаний должна быть специфична для экосистемы C#/.Net.
Для мероприятия с одним треком программа получилась концентрированной. Расписание включает 10 докладов по 15-30 минут, обед в кафе и кофе брейки – и все это с 10.00 до 17.00.
Темы: от архитектуры .Net приложений до механики решений по формированию команд и распределению задач. И, конечно же, управление проектом и исходным кодом. Докладчики представят две полярные парадигмы – классическую Application Lifecycle Management на базе TFS и альтернативные подходы с применением Git и DevOps инструментов.
Наши спикеры начинали как C#/.Net разработчики, но многие имеют опыт руководства коллективами и проектами с десятками и даже сотнями разработчиков.
Вне всяких сомнений, Pro Git — это одна из лучших книг про систему контроля версий git. Совсем недавно появилось второе издание этой замечательной книжки. Большие изменения произошли в издательском процессе: исходный код книги теперь хранится в AsciiDoc, а не в Markdown, а различные форматы (PDF, ePub и Mobi) автоматически генерируются с помощью O'Reilly Atlas platform. Разработка книги активно ведётся на гитхабе, актуальная online-версия находится в открытом доступе на официальном сайте, а любители печатной продукции могут заказать себе экземпляр на Amazon. Второе издание получилось почти в два раза больше первого: на сегодняшний день PDF-версия содержит 570 страниц. Помимо улучшения старого материала, книжка также пополнилась новыми главами и разделами:
Некоторое время назад при старте нового проекта было решено попробовать использовать Git вместо Subversion. Через некоторое время коллектив разделился на тех, кто любит Git (программисты), и тех, кто его ненавидит (дизайнеры и художники). Эксперимент по замене Subversion на Git провалился и на горизонте замаячила перспектива возвращения Subversion.
Почесав репу и содрогнувшись от связанных с Subversion воспоминаний мужики решили: «А что, мы же программисты!» и запилили свой Subversion с Git-ом и печеньками. Так родился проект git-as-svn.
Теперь мы можем использовать и Git, и Subversion с одним и тем же репозиторием. Причем доступ через Subversion напрямую использует данные Git-репозитория, в отличие, скажем, от SubGit, где для Subversion используется отдельный репозиторий.
Халява — студенческая богиня, к которой студенты взывают накануне экзамена, вместо подготовки к нему. Но несмотря на то, что сессия далеко, её величество халява может дать знать о себе даже сейчас и принести пользу. И речь в данном случае о инструментах доступных студентам бесплатно.
В первой части мы познакомились с использованием Fossil в однопользовательском режиме на одном рабочем месте. Следующий шаг — перенос репозитория на другой компьютер — с работы на домашний, или на ноутбук, который мы берем с собой в поездку. Самый простой вариант — это просто скопировать репозиторий, благо это всего один файл, на новое рабочее место. Можно так и сделать, но самое простое решение не всегда самое лучшее, есть вероятность, что возникнут небольшие проблемы.
Большинство людей, впервые узнающих об автоматической сборке, вероятно, относятся к ней с осторожностью: избыточные трудозатраты на ее организацию и поддержание работоспособности вполне реальны, взамен же им предлагается лишь призрачное улучшение эффективности разработки в будущем. Кто же не понаслышке с ней знаком – более оптимистичны, поскольку знают: ряда проблем при работе с их системой гораздо проще избежать, пока они еще не сформировались, нежели когда становится уже поздно все менять.
Так чем же таким может быть интересна автоматическая сборка, какие возможности можно реализовать с ее помощью и каких результатов достичь? Попробуем разобраться.
Я отработал 1,5 года в большой большой компании, которая занимается оптовыми и розничными поставками нефте-газового оборудования (оборот около 30ккк рублей). Внутри внедрена система управления (разработана на 1С), включающая несколько конфигураций для нескольких бухгалтерий, складов и т.д. Около 2к пользователей, работающих в системе ежедневно.
Поддерживает и развивает всю систему команда аналитиков. За это время у нас выработались правила, которые, по моему мнению, помогут всем аналитикам (бизнес, требований) и менеджерам, сотрудникам поддержки и даже немного разработчикам в крупном enterprise сегменте.
Относительно недавно здесь публиковался опрос по используемым системам контроля версий. Как и ожидалось, с большим отрывом победил Git, а Fossil даже не был включен в список, только в комментариях пару раз промелькнул. Поиск по Хабру показал, что здесь о Fossil практически ничего не писали. Поэтому я и решил опубликовать эту статью — тем более, что русскоязычная информация о Fossil крайне скудна и однообразна.
Иногда, исследуя чужие репозитории на github, замечаешь ошибки, неточности или же понимаешь, что мог бы добавить что-нибудь полезное, но, кого-то необходимость выполнять кучу действий в командной строке может отпугнуть, кому-то она в данный момент не доступна, и мы проходим мимо.
Многие опытные пользователи github-а знают, что отнюдь не для всего обязательно нужно использовать командную строку. Все это так.
Здесь я собрал несколько рецептов, используя которые, вы сможете без единой команды git, скопировать себе репозиторий, создать там вспомогательную ветку, в ней что-то отредактировать, добавить/удалить файлы/папки, сделать пулл-реквест в оригинальный репозиторий. А по истечению какого-то времени, когда в оригинальном репозитории накопятся изменения не отраженные в нашей копии — синхронизировать эти два репозитория — причем тоже без единой git-команды.
Продолжаю удивляться делиться опытом перехода из SVN на TFS (или как правильно подметили Team Foundation Version Control (TFVC)).
В предыдущем посте был описан опыт чисто системы управления версиями.
В этом посте я хотел бы поделиться маленьким (но важным) сценарием использования интеграции системы «контроля версиями» с системой «управления дефектами» (или как это называется Work Item Tracking).
Не так давно один из проектов, в котором я участвую, перевели из SVN на TFS. Этот проект (десятки тысяч файлов, включая двоичные файлы) много лет жил и развивался под SVN. Поработав несколько месяцев после перехода, появился некий опыт, которым хочется поделиться.
Важно понять, что это опыт человека после SVN. Я использовал TortoiseSVN (плагин для Windows Explorer) и AnkhSvn — для Студии.
Вчера Atlassian выпустила обновление своего сервиса Bitbucket. Полностью обновился интерфейс, и добавилось немного интересных багов фич. Под катом приведу краткий обзор нововведений на основе записи в блоге разработчиков, ну или можно сразу потыкать у себя в браузере.
В текущей версии GitHub для Windows, мы сделали небольшое изменение, которое имеет едва заметный эффект, который вы, вероятно, уже заметили. Мы изменили подход к слиянию *.csproj и похожих файлов, используемый по умолчанию.
Если вы измените .csproj файл в ветке и затем объедините ее с другой веткой, то вы возможно столкнетесь с большим количеством конфликтов слияния, нежели вы могли иметь раньше.
Предварительно делал поиск по хабру с надеждой на подобный пост, смог найти только вот этот пост, в котором вся работа производятся через TortoiseGit.
Но это не наш метод. По той причине, что в этом случае все наши IDE не смогут сами сделать Push на сервер. Да и через Git Bash ничего не получится сделать на сервере.
почему мне нужно использовать Git в связке с Putty?
Так уж получилось, что я активно использую Putty с настроенными ключами для доступа к серверам. Ключей у меня не один. Git-репозитариев тоже не один.
Конечно же, можно нагенерить OpenSSH ключей для Git-а и разрулить их через ~/.ssh/config, но это получается двойная работа – поддержка ключей в Putty и отдельная поддержка для Git.
Итак, представим, что у нас девственно чистая система, в которой нет ни Putty, ни msysgit. Приступим к настройке нашего рабочего окружения.
Установка Putty
Качаем, устанавливаем, генерим и настраиваем ключ c Pagent (инструкция, ?).
Добавляем ключ на git-сервер
Копируем публичный OpenSSH ключ из Putty-ключа
Запускаем Putty key Generator
Открываем (кнопка «Load») наш PPK-ключ
Копируем весь текст из блока «Key»
Открываем страницу с SSH ключами и добавляем из буфера наш ключ
В картинках (на примере GitHub)
Создаём и сохраняем в Putty профиль «git@github.com» и проверяем, что удаётся зайти по ключу – должна открыться и сразу закрыться консоль.
GitHub сегодня анонсировал запуск GitHub Developer Program, предназначенной для лучшего информирования разработчиков о происходящих изменения и коллективной работы над улучшением сервиса.
Члены GitHub Developer Program будут получать уведомления об изменениях в GitHub API, а также самый ранний доступ к новым функциям. У участников программы кроме того будет возможность запросить лицензию разработчика для GitHub Enterprise и размещать свои инструменты для рассмотрения на новой странице интеграции, также запущенной сегодня.
Приветствую вас, коллеги! Сегодня утром гитхаб опубликовал подробную статью о свежевышедшой версии git. Забрать ее, как обычно, можно на официальном сайте, а под катом — краткий перевод что нового и интересного: push-to-deploy, ручное управление параметрами SSH, способ предотвратить зависание cron скриптов с клиентом git и многое другое.
Некоторое время назад при старте нового проекта было решено попробовать использовать Git вместо Subversion. Через некоторое время коллектив разделился на тех, кто любит Git (программисты), и тех, кто его ненавидит (дизайнеры и художники). Эксперимент по замене Subversion на Git провалился и на горизонте замаячила перспектива возвращения Subversion.
