Working With People Adl Uni

2,574 views

Published on

Talk given to students at Adelaide University on 20 March 2008 about how we do software development in teams at Rising Sun Pictures


Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,574
On SlideShare
0
From Embeds
0
Number of Embeds
579
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Working With People Adl Uni

  1. 1. Working with people (and some technology that helps) matthew.landauer@rsp.com.au Rising Sun Pictures
  2. 2. • #!/usr/bin/env ruby # # quot;Hello worldquot; puts quot;Hello Worldquot;
  3. 3. • $ sudo cp helloworld /usr/local/bin $
  4. 4. What happens when you’re not working on your own?
  5. 5. Things get a whole lot more difficult and complicated
  6. 6. About Rising Sun Pictures • Australian visual effects company • Focus entirely on producing visual effects for feature films • Founded 13 years ago
  7. 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. 8. Version Control • At RSP we use Subversion for software version control
  9. 9. Version Control • Subversion (SVN) • Central repository • Tracks each change made by each person • Supports branches
  10. 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. 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. 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. 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. 14. Bug tracking • We use a commercial bug tracker called JIRA www.atlassian.com/software/jira/
  15. 15. Bug/version control integration
  16. 16. 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
  17. 17. 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
  18. 18. Getting releases out on time
  19. 19. 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
  20. 20. Needs Sounds like a recipe for chaos!
  21. 21. Needs Our solution: The “need” system For example: • $ need publish_3.6
  22. 22. Job environment • $ job bb • [bb|common|global] • $
  23. 23. 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
  24. 24. Deployment
  25. 25. 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
  26. 26. The Future • Open source bug tracking tools keeps getting better • Distributed version control is gathering momentum, especially in the open-source community.
  27. 27. 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!
  28. 28. Distributed version control • Mercurial - http://www.selenic.com/mercurial/ • Git - http://git.or.cz (Also see Linus Torvalds Google Tech Talk - google “torvalds git”)
  29. 29. Distributed version control No need to give anyone “commit access”
  30. 30. Distributed version control For those working on “Earth” you’re going to be using git!
  31. 31. Distributed version control Mary’s external repo Jane’s external repo Push Push Pull Mary’s repo Jane’s repo
  32. 32. 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
  33. 33. Questions?

×