Rising Sun Pictures is a visual effects company located in Adelaide and Sydney with 120 employees. They work primarily for US clients producing visual effects for feature films. The company uses Subversion for version control of their software, allowing them to track changes made by different people and know what has changed when things break. They also use JIRA for bug tracking and have integrated it with their version control system. This helps when new features are added and people need to understand why and when changes were made. The company has processes for continuous integration, deployment, and versioning to help manage their many projects and keep everything running smoothly across offices.

1. Working with people
(and some technology that helps)
matthew.landauer@rsp.com.au
Rising Sun Pictures

2. • #!/usr/bin/env ruby
#
# quot;Hello worldquot;
puts quot;Hello Worldquot;

3. • $ sudo cp helloworld /usr/local/bin
$

4. What happens when you’re not working on your own?

5. Things get a whole lot more difficult and complicated

6. About Rising Sun Pictures
• Australian visual effects
company
• Focus entirely on
producing visual effects
for feature films
• Founded 13 years ago

7. 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

8. Version Control
• At RSP we use Subversion for software version
control

9. Version Control
• Subversion (SVN)
• Central repository
• Tracks each change made by each person
• Supports branches

10. 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?

11. 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

12. 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]”

13. 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

14. Bug tracking
• We use a commercial bug tracker called JIRA
www.atlassian.com/software/jira/

17. Bug/version control integration

19. You’re asked to add a feature
• 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

20. 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

21. Getting releases out on time

22. 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

23. Needs
Sounds like a recipe for chaos!

24. Needs
Our solution:
The “need” system
For example:
• $ need publish_3.6

25. Job environment
• $ job bb
• [bb|common|global]
• $

26. 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

27. Deployment

28. 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

29. The Future
• Open source bug tracking tools keeps getting better
• Distributed version control is gathering momentum,
especially in the open-source community.

30. 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!

31. Distributed version control
• Mercurial - http://www.selenic.com/mercurial/
• Git - http://git.or.cz (Also see Linus Torvalds Google
Tech Talk - google “torvalds git”)

32. Distributed version control
No need to give anyone “commit access”

33. Distributed version control
For those working on “Earth”
you’re going to be using git!

34. Distributed version control
Mary’s external repo Jane’s external repo
Push Push
Pull
Mary’s repo Jane’s repo

35. 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

36. Questions?