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

В данной статье представлен опыт использования системы версионного контроля subversion и системы отслеживания изменений Trac в рамках учебного процесса по дисциплине «Лингвистическое и программное обеспечение САПР» на каф. КСУП ТУСУР. Показаны преимущества, которые получили студенты и я, как преподаватель, от использования этих систем в учебном процессе.

… Или как автоматизировать некоторые действия в TFS 2010.

Сразу скажу, что для TFS 2012 автор обещает быстро выпустить обновленную версию, однако, на мой взгляд, с учетом того, что API не поменялось или мало поменялось, то данный небольшой проект вполне может завестись и на новом TFS 2012 RC.

Идея

Мои последние статьи (раз, два) повествуют о настройке шаблонов процессов для TFS, но данные шаблоны оторваны друг о друга, по сути, хотя и связываются в работе связями типа: Child, Parent, Related To и так далее. Было бы логично использовать эту связь, для добавления интерактивности во всю схему, чтобы элементы действительно были связанны, чтобы они действительно реагировали на состояния друг друга в зависимости от типа связи и состояния. Чтобы можно было делать некоторые аккумулирующие подсчеты в метриках, ведь все эти данные доступны и их можно использовать в автоматическом режиме, сокращая время рутинных действий.

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

Например, представим себе ситуацию, когда пользовательская история имеет полный набор артефактов и готова к работе, созданы конкретные задания для реализации этой истории. В данной ситуации история находится в состоянии Ready For Development, а все задачи в состоянии Proposed. Разработчик берет задачу в работу, меняет ее состояние на Active. Далее он должен поменять состояние истории на WIP (Work In Progress). Однако этот шаг ведь можно автоматизировать! А автоматизация в свою очередь ведет к большему порядку и красоте. Т.е. как только разработчик взял задачу в работу, состояние всей истории поменялось автоматически!

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

Github совершает новый шаг вперед: впервые с момента основания в 2008 году компания получает инвестиции. Администрация репозитория свободного кода сообщила в понедельник о договоренности по финансированию в 100 млн. долларов США от фонда Andreessen Horowitz на улучшение и расширение платформы, которая уже стала промышленным стандартом для управления и поиска кода в сети. Фонд оценил стоимость компании в 750 млн. долларов США.

Питер Левин, партнер фонда Andreessen Horowitz, присоединится к команде Github. Денежные средства будут использованы для найма дополнительных сотрудников и расширения на новые платформы, например, на мобильные устройства. Исполнительный директор Github Том Престо-Уэрнер выразил надежды не только разработать новые функции, но и улучшить старые, к примеру, веб-приложения для различных операционных систем. Планируется сделать Github удобным широким массам клиентов, от энтузиастов до крупных компаний, от разработчиков программного обеспечения до дизайнеров и писателей.

Много лет подряд в качестве системы контроля версий для большого количества проектов использовали только SVN. Но наступил момент, когда количество разработчиков на одном из проектов заметно увеличилось, проект уже запущен в работу, и нужно как активно разрабатывать параллельно несколько фич, так и фиксить уже имеющиеся баги в оперативном режиме. Единый trunk в SVN не позволяет этого делать, а организация бранчей в нем же превращает жизнь разработчиков в ад. Поэтому было принято решение о переезде этого проекта с SVN на Git.

По информации близких к руководству венчурного инвестиционного фонда Andreessen Horowitz источников сайта PandoDaily.com, GitHub скоро начнёт первый раунд финансирования. Точная сумма и условия сделки пока неизвестны, но, по предварительным данным, компания на этом этапе будет оценена в 500 — 800 миллионов долларов. До сих пор Гитхаб развивался самостоятельно, не прибегая к помощи инвесторов. Сейчас в нём пятьдесят пять сотрудников.

На Гитхабе зарегистрировано 1.6 миллиона пользователей и 2.8 миллиона репозиториев. Платная подписка для индивидуальных пользователей стоит от 7$ в месяц, а цены на Enterprise-версию, устанавливаемую внутри корпоративной сети, начинаются с 5000$ в год. Крупные компании тратят на услуги Гитхаба до миллиона долларов в год.

Официальных комментариев от компании GitHub пока не поступало.

Скоро выходит Team Foundation Server 11. Это новый крупный выпуск, который включает в себя много нового как для разработчиков, так и для менеджеров проектов, тестировщиков и аналитиков.
В Team Foundation Server 11, вводится новая версия, которая называется Team Foundation Server Express.

В этой публикации будет рассказано именно о бесплатной редакции Express. Публикация предназначена для начинающих разработчиков и тех, кто еще не работал с Team Foundation Server.

Преамбула:
Имеем в наличии TortoiseSVN и Total Commander, и активно их используем в работе.
Практически все действия в Total Commander'e успешно совершаются одной только клавиатурой, без использования мышки, какими-либо горячими клавишами. Главное их найти/знать/привыкнуть, и работа становится в разы проще и быстрее.
TortoiseSVN же из коробки предоставляет нам только пункты в контекстном меню, до которого можно добраться двумя способами:

• Мышкой. При активной работе, тянуться каждый раз до мышки, реально начинает напрягать уже через пару дней/часов/минут работы (зависит от крепости нервов разработчика) и времени занимает это довольно много.
• Через клавишу контекстного меню + стрелок. Этот вариант конечно чем-то проще и быстрее (ибо не надо тянуться за мышкой), но всё так же не удобен и всё такой же медленный.

Хочется все действия с TortoiseSVN выполнять так же быстро, как и действия в самом Total Commander'e.
Т.е. через горячие клавиши, в одно нажатие.

Облазив просторы интернета, не смог найти ни одной инструкции, как можно по-человечески интегрировать TortoiseSVN в Total Commander и сделать это возможным.
Поэтому решил написать свой небольшой простенький мануал.

При клонировании репозитория с помощью команды

hg clone A B

mercurial сначала пытается создать жесткие ссылки для файлов внутри папки .hg в новом репозитории. Это ускоряет клонирование и экономит место на жестком диске.

Жесткие ссылки поддерживаются файловыми системами Linux и Windows NTFS. Для файловых систем, которые не поддерживают жесткие ссылки (например Windows FAT), а также при клонирование через http/https или ssh с удаленного сервера mercurial полностью копирует все файлы.

Добрый день, коллеги.

Длинные праздники заканчиваются, и уже завтра, мы снова погрузимся в пучину ежедневной рутины. Сегодня, на стыке еще не закончившихся праздников и еще не начавшейся рабочей недели, я бы хотел немного рассказать о непрерывной интеграции.
Начиная внедрять Agile практики в разработке, многие, прочитав: «Личности и их взаимодействия важнее, чем процессы и инструменты», приходят в восторг. Ведь можно собрать команду, сплотить их, поставить задачи и вот она: «звезда пленительного счастья» (работающее и полезное пользователям ПО). Но, к сожалению, в жизни бывает все намного скучнее и непредсказуемей. Начиная внедрять новомодный Scrum или Kanban, часто забывают, что все достоинства этих методик проявляться только в том случае, если они ложатся на правильные инженерные практики. К таким практикам относят модульное тестирование вообще, и TDD в частности; парное программирование; Code Review; непрерывную интеграцию и многое другое.
Под катом, я попробую показать, как настроить непрерывную интеграцию в рамках TFS 11 и в каких сценариях, какой способ построения проектов будет наиболее оправдан (много картинок и текста).

Вот и мне посчастливилось познакомиться с git. Каюсь, пользуясь Subversion, я знал, как в IDEA или TortoiseSVN сделать то, что мне надо, но даже не представлял, что происходит за сценой. В данном случае я решил подойти к git более ответственно и хорошенько изучить его перед использованием. Сейчас я знаю какие команды надо использовать для выполнения задуманного, но не знаю, как это сделать в IDEA или TortoiseSVN.
Но я решил пойти еще дальше и узнать, что происходит в самой директории .git. Там оказалось все настолько интересно и просто, что я решил поделиться этим с вами.

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

Если вы не понимаете, что побудило сделать git именно таким, то вас ждут страдания. Используя множество флагов (--flag), вы сможете заставить git работать так, как по вашему мнению он должен работать, вместо того, чтобы работать так, как git того хочет. Это как забивать гвозди отверткой. Работа делается, но хуже, медленнее, да и отвертка портится.

Гуляя по github'у я много раз видел в разных репозиториях одновременно и теги вида «v2.3.4» и коммиты с сообщениями типа «Bump version» и сменой номеров версии где-нибудь в lib/version.rb. И всегда мне казалось — что-то тут лишнее.

И когда пришло время задуматься и мне над расставлением номеров версий, я сказал: «Нет! Я не буду прописывать эти номера в файлы руками. Пусть это делает за меня моя система контроля версий!»

Как ни странно, но среди программистов ещё довольно много тех, кто не видит смысла в системах контроля версий (СКВ) или попросту не знает о них. Хватает и тех, кто знает, но не в курсе с чего начать внедрение или, при использовании, проходят мимо очень удобных возможностей.

Доброго времени суток!

Данная статья посвящена одной небольшой задачке – переносу репозитория вместе со всей историей с одной системы управления версиями в другую, а точнее – в SVN. Речь пойдёт об использовании бесплатной утилиты Importer for SVN от Palarion, с помощью которой можно мигрировать с CVS / PCVS / VSS / ClearCase / StarTeam / MKS на SVN, не потеряв при этом журнала изменений кода. В моём случае потребовалось перенести проекты из Borland StarTeam.

Почему было сказано «нет» StarTeam и «да» SVN? Сначала думал пропустить данный абзац во избежание холиваров. Но, пожалуй, без этого статья была бы лишена, скажем так, области определения. В моём случае отказаться от StarTeam вынудил уход человека, его внедрившего и администрировавшего. Пара дней безуспешных попыток заставить работать сервис под другой учётной записью породили мысль о том, что задача восстановления репозиториев из бэкапов станет ещё большим вызовом. Конечно, радиус кривизны рук можно было значительно увеличить спустя какое-то время. Но оно нам надо, спрашивается, когда есть бесплатный, до безобразия лёгкий в установке и поддержке SVN? Тем более что у меня было предостаточно опыта его использования на предыдущих местах работы, а все два с половиной разработчика находятся в одной комнате.

Одно препятствие – жаль было терять историю изменений. Сначала думали залить в SVN текущие версии, а историю смотреть в StarTeam, переведя его предварительно в read-only. Но, как говорится, это не наш метод. И непродолжительный гуглопоиск навёл на выше в суе помянутый Palarion Importer for SVN.

Чтобы управлять доступом можно использовать различные решения gitosys, gitolite, mercurial-server, но эти решения работают через SSH, что не всегда удобно (должен быть ключ). В добавок не хватает гибкости у подобных решений.

Основные требования:

• доступ по логину/паролю (HTTPS)
• контроль прав на чтение/запись
• публичный/приватный репозиторий
• управления всем через веб интерфейс
• все данные (информация о проекте и пользователях) должны храниться в базе (MySQL)

Для решения этой задачи сделал следующую систему…

Способов хостинга mercurial репозиториев достаточно, но я сочинил именно такой вариант по следующим причинам:

1. nginx: мало кушает, быстро работает — скорость
2. supervisor: мониторит процесс, перезапускает если что — надёжность
3. gunicorn: wsgi, большие возможности по настройке — эффективность

Кроме того, т.к. я разрабатываю на django, и сайты запускаю под этой же связкой, есть и четвёртая причина — унификация, а она очень полезная вещь.

Если вас заинтересовала тема, то конкретные инструкции и конфиги — под катом.

Данный зверь будет полезен тем, кто не пользуется GUI утилитами при работе с git, mercurial и т.д., а чувствует себя комфортно работая с ними из консоли.
vcprompt.com — python скрипт, который будет выводить основную информацию по версии VCS в текущей директории, если такова есть. Как то название VCS, текущую ветку, были ли изменения с последнего коммита и ещё несколько параметров, которые можно задать в формате вывода.

Статистика Debian позволяет вполне объективно сравнить популярность различных систем управления версиями. Git на графике обозначен зелёным цветом.


^{Количество инсталляций систем управления версиями за 2004-2011 гг}

Статистика собирается с пользователей, которые установили пакет popularity-contest (popcon). После установки popcon еженедельно отсылает в Debian по электронной почте информацию об установленных в системе пакетах и времени последнего использования.

Cruise Control — одна из достаточно большого количества CI (continuous integration) систем. Речь пойдет о том, как настроить ее для связи с SVN и деплоя сайта на .NET.

Для начала немного о задачах СС на данном сервере:

• Взять код из SVN репозитория
• Скомпилировать его
• Положить в директорию к IIS

Далее будут выложены куски конфигурационного файла, с комментариями по каждой хоть как-то интересной строчке. По кускам, фактически выложен полный рабочий конфиг.