working with people adl uni
DESCRIPTION
Talk given to students at Adelaide University on 20 March 2008 about how we do software development in teams at Rising Sun PicturesTRANSCRIPT
Working with people(and some technology that helps)
[email protected] Sun Pictures
• #!/usr/bin/env ruby## "Hello world"
puts "Hello World"
• $ sudo cp helloworld /usr/local/bin$
What happens when you’re not working on your own?
Things get a whole lot more difficult and complicated
About Rising Sun Pictures
• Australian visual effects company
• Focus entirely on producing visual effects for feature films
• Founded 13 years ago
About Rising Sun Pictures
• Offices in Adelaide and Sydney
• 120 people
• In the last five years the vast majority of our work has been for US clients
Version Control
• At RSP we use Subversion for software version control
Version Control
• Subversion (SVN)
• Central repository
• Tracks each change made by each person
• Supports branches
Version Control
• We simply couldn’t function without it
• There are too many people working on the same code
• When something breaks, how else would we know what’s changed?
Commit often
• Commit when you’ve made an “atomic” change
• A general rule of thumb - you should be committing at the very least several times a day
• Don’t commit something that breaks the unit tests
Commit comments
• Tell people why you made a change. Remember the code tells people what you changed
• Consider your words carefully and keep it brief
• Include information about which bug/feature is being addressed
• Example: “Log the latest history key-value entries to a seperate metadata file in version directory [PUBLISH-496]”
Bug tracking
• We have more than 12000 bug/feature tickets in our system
• More than 2000 of those are currently open
• This is way too much for any person to keep in their head
Bug tracking
• We use a commercial bug tracker called JIRA www.atlassian.com/software/jira/
Bug/version control integration
• Things have changed since the last time you looked at the code
• Why were the changes made? Who made them? When were they done? Who was involved in the discussions about these new features?
• You simply couldn’t answer these questions easily unless version control and bug tracking fitted together
You’re asked to add a feature
Getting releases out on time
• Agile
• Short iterations of work
• Estimate the work that goes into each release
• Plan what goes into each release so that you can achieve your deadline
Getting releases out on time
Needs
• RSP has about 200 software projects
• Each project has around 10 versions deployed
• RSP is working on six different movies at the moment spread across two offices
• Each movie might be running a different version of each piece of software
Needs
Sounds like a recipe for chaos!
Needs
Our solution:
The “need” system
For example:
• $ need publish_3.6
Job environment
• $ job bb
• [bb|common|global]
• $
Deployment
• Builds applications on multiple architectures automatically
• Only allows deployment when unit tests pass
• Integrates with RSP’s “need” system
• Every deployment happens in both Adelaide and Sydney
• Versions the releases automatically
• Notifies people of the new release by email
Deployment
The result
• Once projects are set up they are very easy to deploy
• Deployments are consistent
• Fewer mistakes
• Deploying new versions of software will never change anything for the user until they specifically request that new version
The Future
• Open source bug tracking tools keeps getting better
• Distributed version control is gathering momentum, especially in the open-source community.
Distributed version control
• No central repository
• When you a copy (“clone”) a repository it copies the entire history
• You make all the commits to your local repository (on your own machine) - works even when there is no network. Great for working on the train!
Distributed version control
• Mercurial - http://www.selenic.com/mercurial/
• Git - http://git.or.cz (Also see Linus Torvalds Google Tech Talk - google “torvalds git”)
Distributed version control
No need to give anyone “commit access”
Distributed version control
For those working on “Earth”
you’re going to be using git!
Distributed version control
Mary’s external repo Jane’s external repo
Mary’s repo Jane’s repo
Push PushPull
What you’ve seen today
• Some reasons why working in a team is harder than working on your own
• Version control
• Bug tracking
• Automated software deployment
• A bit about the future of version control
Questions?