Working with people(and some technology that helps)

matthew.landauer@rsp.com.auRising 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?