В: В чем разница между безработным программистом и предпринимателем?
A: Вы тоже не знаете?
Экономика в упадке, и это отстой, но это хорошая новость для инноваций. Люди повсюду создают стартапы. Многие из вас потерпят неудачу — некоторые из-за бесконечного промедления, некоторые из-за плохого маркетинга, а некоторые из-за старомодной неудачи. Но некоторые из вас преуспеют. Вот что делает это стоящим.
Я работал со стартапами со всех концов спектра. Некоторые успешно обналичили деньги; некоторые с несколькими раундами финансирования, а некоторые боролись за выживание. Совсем недавно я работал с Арло Белши и Ким Уоллмарк над нашим стартапом Подробнее об этом позже.
Из этого опыта я узнал кое-что о разработке программного обеспечения в предпринимательской среде. Это эссе является первым из серии, которая поможет вашему запуску добиться успеха или, по крайней мере, не потерпит неудачу по причинам разработки программного обеспечения. Выключить World of Warcraft и приступить к работе? Это твоя работа.
Почему процесс имеет значение
Моя область — это программный процесс, в частности Agile методы. Один из основателей, с которым я разговаривал, придумал идею процесса. «У нас нет времени на процесс», — сказал он. «Мы должны сосредоточиться на удовлетворении наших клиентов».
Это действительно отличное отношение. И этому основателю повезло иметь платящих клиентов и реальную прибыль. Но часть о процессе? Совершенно неправильно.
«Процесс» — это не что иное, как то, как вы делаете свою работу . Улучшение процесса: улучшение работы. Гибкие процессы — это способы работать лучше. Это так просто. Не обманывайте себя лохов, которые покупают модели зрелости CMM (или, черт побери, модели гибкости зрелости) — улучшение процессов не означает большого количества бюрократии, накладных расходов или дорогостоящих сертифицированных вещей. Это значит делать свою работу лучше . Вот о чем эта серия: лучше делать свою работу.
Хватит разговоров. В этом эссе мы рассмотрим один из способов улучшить ваши рабочие привычки.
Автоматизируйте ваш релиз
Часть секрета высокопроизводительной разработки программного обеспечения находится в зоне. Некоторые люди называют это потоком . Это такое состояние ума, когда у вас все ясно в голове, вы точно знаете, что делаете, и вы настроили весь остальной мир.
Поток трудно достичь и легко потерять. Любое существенное прерывание вырывает вас из зоны, и все эти тонкие умственные структуры рушатся. Ваша производительность резко падает, когда вы справляетесь с прерыванием. Когда вы будете готовы вернуться к работе, для возвращения в зону , по словам Тома Демарко и Тимоти Листера , потребуется много времени — пятнадцать минут .
( Парное программирование — один из способов снизить стоимость прерываний, но это эссе на другой день.)
Один из способов убить поток — это неуклюжий процесс сборки и развертывания. Строит своего рода органично, как грибок. Здесь сборка IDE, там FTP, там сессия ssh. Прежде чем вы это узнаете, создание и развертывание приложения — это серьезная проблема, которая в хороший день занимает полчаса, и вам повезло, если сломается только одна вещь.
Предотвратите это нарушение, создав сценарий автоматической сборки и развертывания. Это не обязательно должно быть идеально, но нужно вносить небольшие улучшения по мере выявления болевых точек. Одним из ключей к улучшению процесса является осознание того, что несовершенное улучшение лучше, чем отсутствие улучшения. Шесть месяцев несовершенных улучшений подряд приводят к довольно удивительным результатам.
Пример из реального мира
Как я уже упоминал, я сейчас работаю над стартапом с Арло Белши и Ким Уоллмарк. Вот сценарий сборки и развертывания, который мы написали для первого продукта нашего стартапа. Версия, которую я собираюсь показать, находится в разработке примерно через 12 дней. Сценарий не идеален — далеко не так — но он позволяет нам безболезненно выпускать наше программное обеспечение. Мы улучшили его с течением времени, и мы будем продолжать это делать.
Во-первых, вот наш грабли. ( Rake — это система сборки на основе Ruby, которая мне нравится.) Rakefile — это основная сборка для системы. Чтобы собрать и протестировать, мы набираем rake; для создания, тестирования и развертывания мы набираем грабли. Я добавил несколько комментариев, чтобы помочь вам понять, что происходит. Выделенные цели — те, которые мы запускаем из командной строки.
require 'qunit_runner.rb' # A runner we wrote for unit testing Javascript
task :default => :test # Run the 'test' target if no target provided
task :python do # Builds the python (server-side) code
sh "cd app && python setup.py develop"
end
task :database_schema => :python do # Rebuilds the database schema
touch "app/devdata.sqlite"
rm "app/devdata.sqlite"
sh "cd app && tg-admin sql create"
end
task :server_test do # Tests the server-side Python code
sh "testserver"
end
task :client_test do # Tests the client-side Javascript code using our custom qunit_runner.rb
run_qunit
end
desc "Run tests" # Used from command-line
task :test => [:server_test, :client_test]
desc "Start local server" # Used from command-line
task :serve => [:python, :database_schema] do
sh "cd app && python start-product.py"
end
desc "Deploy to production server" # Used from command-line
task :ship => :test do
sh "ship.bat"
end
В этой сборке есть несколько интересных вещей. Во-первых, в этом нет ничего особенного. Большая часть тяжелой работы выполняется пакетными файлами. Это пример его несовершенства. Со временем автоматизация была собрана по частям, и пока не было достаточно веских причин для объединения файлов в основную сборку. По мере того, как сборка становится больше, нам придется улучшать способ обработки модульности, потому что скрипты станут громоздкими, если мы этого не сделаем.
С другой стороны, одна из лучших вещей, которую мы сделали, — это потратить время и силы на то, чтобы сервер localhost работал и был автоматизирован. Мы набираем rake serve и можем запускать все, что отключено от сети Это позволяет нам создавать и тестировать изменения, не нарушая работу других. Я настоятельно рекомендую вам сделать это, если вы еще этого не сделали.
(Локальные серверы кажутся вам легким делом? Хорошо. Вы будете удивлены, как много людей не делают этого.)
Сборка Python — это стандартный файл сборки TurboGears, и я собираюсь рассказать об автоматизированных тестах в следующем эссе, поэтому давайте перейдем к автоматическому развертыванию. Когда мы набираем rake ship, rakefile собирает и тестирует, а затем вызывает ship.bat, пакетный файл Windows.
# Change backwards slashes into forward slashes so rsync works
set PRODUCT=%CD:~2,255%\app\
set PRODUCT=%PRODUCT:\=/%
set BIN_DIR="%CWRSYNC_LOCATION%\bin\"
if DEFINED CWRSYNC_LOCATION (
pushd %BIN_DIR%
# Copy the deployment tree to the server
rsync.exe --recursive --perms --times --delete --force --delete-excluded --progress --exclude=.svn --exclude=.DS_Store --exclude=*.pyc --exclude=test --include=.* %PRODUCT% [email protected]:/home/example/app
# Bounce the server so it sees the new code
ssh [email protected] ~/bounce-webserver.sh
popd
) else (
# Tell us what environment variables we need to set
echo Set the variable CWRSYNC_LOCATION TO THE directory cwRsync was installed in.
(Example: C:\Program Files\cwrsync)
)
В самом начале мы развернули, запустив Putty и указав вручную копировать файлы. Этого было достаточно примерно на один день, а потом мы немного поболтали с Windows и выяснили, как использовать rsync для копирования нашего кода на сервер. Позже мы добавили аутентификацию с открытым ключом ssh, поэтому нам не нужно было вводить наши пароли, а затем небольшой скрипт, чтобы отослать сервер для нас.
Там еще много чего можно улучшить. Большая часть конфигурации сервера все еще выполняется вручную на сервере. Это повредит, если с сервером случится что-то катастрофическое. Мы могли бы также лучше построить структуру каталогов.
Но в целом, развертывание довольно безболезненно. Мы направили наше внимание в другом месте сейчас. Наше развертывание не идеально, но оно достаточно хорошее, чтобы больше не прерывать поток.
Беспощадный марш несовершенных улучшений
В стартапе вам постоянно приходится балансировать между поставкой программного обеспечения и улучшением ваших возможностей доставки. Давление ситуации имеет тенденцию подчеркивать «доставить», а не «улучшить». Это нормально, пока вы не идете назад. Многие из стартапов, которые покупают мои консультационные услуги, накопили годы ярлыков, и это лишило их возможности вводить новшества. Изменения в их коде настолько дороги и подвержены ошибкам, что они решают выбросить все это и начать все сначала. К этому моменту у команды разработчиков возникло серьезное разочарование и начались дискуссии о разработке аутсорсинга. Хлоп. Не делай этого.
Величие возникает из неустанного марша несовершенных улучшений. Крошечное улучшение сегодня обеспечивает лучшее улучшение завтра, что дает еще большее улучшение на следующий день и на следующий день. Прежде чем вы это узнаете, вам будет веселее работать в своей «устаревшей» кодовой базе, чем над совершенно новым кодом. Возможно! Я видел это.
Что касается нас, то понадобилось около половины дня, чтобы понять, как заставить Rsync хорошо играть с Windows. Создание остальной части сценария сборки тоже не было бесплатным. Учитывая, что у нас менее месяца разработки под нашими поясами, я не думаю, что мы пока окупили стоимость. (Хотя трудно увидеть всю боль, которую мы предотвратили.) Несмотря на эту цену, я думаю, она того стоила. Реальное преимущество заключается в том, что мы избавились от всех мыслей и работ по развертыванию. Нам не нужно прерывать поток, чтобы тщательно рассмотреть все вопросы. Мы просто набираем грабли, и все готово.
If building and deploying your code is a distraction (or worse, if you’ve yet to do it), invest a bit of time in a good automated build. It doesn’t have to be perfect. Just make it good enough so that you can stop worrying about shipping and get back to focusing on code.
Further Reading
Chromatic has a nice series of essays over at Modern Perl Books about how to release software:
- Shooting Yourself in the Foot with Customer Branches
- How to Ruin Your Ability to Release Software
- The Rapid Release Tautology
Shane Warden and I write about automated builds in The Art of Agile Development. There’s a summary at Ten Minute Build and additional commentary at Living in the Punch-Card Era.
Diana Larsen and I teach a hands-on Agile delivery course called The Art of Agile Delivery. In that course, you’ll form a team to build a full software product from scratch, and you’ll use build automation and other techniques to ship that product in 90-minute increments. It’s pretty cool. Once you’ve successfully built and released software in a 90 minute cycle, shipping once a week is a doddle.
At the time of this writing, the next course is June 10-12, 2009. There’s a nice early-bird discount if you register prior to April 30th.