This document discusses the history of the oldest Django project, which was originally created for a regional news company with newspapers, TV stations, and magazines. It details the challenges of porting the project to newer versions of Django over many years as Django continued to evolve, including two major porting attempts. Key lessons learned include the importance of preparation, testing, and making deployment automated. The project was later open sourced and the codebase simplified, cutting around 40,000 lines of code.

1. The world’s oldest django
project
James Bennett • PyCon Atlanta • February 19, 2010

2. In the beginning...

3. A regional news company

4. A regional news company
A dozen or so newspapers

5. A regional news company
A dozen or so newspapers
Two TV stations

6. A regional news company
A dozen or so newspapers
Two TV stations
Weekly magazines

7. A regional news company
A dozen or so newspapers
Two TV stations
Weekly magazines
Cable TV/Internet/telephony

12. Those responsible have been sacked

14. “The CMS”

15. “The CMS”

16. “The CMS”

17. “The CMS”

18. “The CMS”

19. Disentangling

20. Disentangling
Mostly done prior to open-sourcing Django

21. Disentangling
Mostly done prior to open-sourcing Django
Though some bits survived

22. Ellington the product

23. Early customers

24. Early customers
Some technically inclined

25. Early customers
Some technically inclined
Some… not

26. Customization

27. Customization
Branch for each client? Bad idea

28. Customization
Branch for each client? Bad idea
Unified codebase? Good idea

29. What is the product?

30. What is the product?
Dogfooding is great for QA

31. What is the product?
Dogfooding is great for QA
But how much of that code should you really sell?

32. What is the product?
Dogfooding is great for QA
But how much of that code should you really sell?
Do you treat your own company as a client?

33. “Removing the Lawrence”

34. Deployment headaches

35. Deployment headaches
Each client runs their own servers

36. Deployment headaches
Each client runs their own servers
Wildly divergent setups

37. Deployment headaches
Each client runs their own servers
Wildly divergent setups
Initial solution: Ellington as a hosted service

38. The port that ate Cleveland

39. Django moves on

40. Django moves on
Django 0.95 and 0.96 released

41. Django moves on
Django 0.95 and 0.96 released
Internal sites pinned to 2006 revision

42. Django moves on
Django 0.95 and 0.96 released
Internal sites pinned to 2006 revision
Hosted client sites pinned to 0.91 release tag

43. http://code.djangoproject.com/wiki/RemovingTheMagic

44. First porting attempt

45. First porting attempt
Automated tools

46. First porting attempt
Automated tools
Built on early versions of Python’s 2to3

47. First porting attempt
Automated tools
Built on early versions of Python’s 2to3
Takes more time than porting by hand!

48. Second porting attempt

49. Second porting attempt
Targeting Django 1.0 (unreleased)

50. Second porting attempt
Targeting Django 1.0 (unreleased)
Partially automated, partially manual

51. The final push

52. The final push
All hands on deck!

53. The final push
All hands on deck!
Testing, testing, testing

54. The final push
All hands on deck!
Testing, testing, testing
Finally relaunched internal sites November 2008

55. What we’ve learned

56. Preparation is important

57. Preparation is important
A real staging server

58. Preparation is important
A real staging server
Internal review before deployment

59. Testing is important

60. Testing is important
Unit tests saved us during the porting process

61. Testing is important
Unit tests saved us during the porting process
Buildbot for continuous integration

62. Testing is important
Unit tests saved us during the porting process
Buildbot for continuous integration
Spidering tools for live testing

63. Deployment is (still) hard

64. Deployment is (still) hard
But automated deployment is a lifesaver

65. Deployment is (still) hard
But automated deployment is a lifesaver
Currently using Capistrano

66. Deployment is (still) hard
But automated deployment is a lifesaver
Currently using Capistrano
Isolated environments

67. Hosting solves a lot of
problems

68. Change control

69. Change control
Completely unified codebase for Ellington

70. Change control
Completely unified codebase for Ellington
Migration framework (South)

71. Change control
Completely unified codebase for Ellington
Migration framework (South)
Custom code isolated as client-specific applications

72. Open source

73. Open source
Non-core functionality being released

74. Open source
Non-core functionality being released
Internal code becomes external dependency

75. Code savings

76. Code savings
Modern Django, open sourcing and jettisoning legacy code

77. Code savings
Modern Django, open sourcing and jettisoning legacy code
Depending on measurements, up to 40k lines of code cut in
porting

78. Reorganization

79. Reorganization
In 2009, one dev team became two

80. Reorganization
In 2009, one dev team became two
Commercial products team

81. Reorganization
In 2009, one dev team became two
Commercial products team
Internal sites team

82. Questions?