Atlassian Developers switch to DVCS - Unite London conference
•Als KEY, PDF herunterladen•
1 gefällt mir•513 views
Discussion of how Atlassian moved from subversion source code management to DVCS tools such as Git and Mercurial. Covers a basic recipe for making the switch from the Atlassian experience and ideas as to why DVCS has become a competitive advantage to businesses.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie Atlassian Developers switch to DVCS - Unite London conference
Ähnlich wie Atlassian Developers switch to DVCS - Unite London conference (20)
Mehr von John Stevenson
Mehr von John Stevenson (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Atlassian Developers switch to DVCS - Unite London conference
- 3. build it check get in Task write code
- 4. DVCS @ Unite Issue Tracker
- 5. DVCS @ Unite Content Collaboration
- 6. Shaping the future of DVCS
- 7. Making the Switch to DVCS How Atlassian teams moved from centralised to distributed version control John Stevenson, UK Ambassador, Atlassian 7
- 10. Importance of Versioning Collaboration History of changes Multiple copies
- 11. Importance of Versioning Collaboration History of changes Multiple copies
- 12. Importance of Versioning Collaboration History of changes Multiple copies
- 13. One repository to rule them all
- 14. One repository to rule them all
- 15. Whats the beef with Subversion ?
- 16. Centralised Version Control Subversion
- 17. Centralised Version Control Subversion
- 18. Centralised Version Control Subversion
- 19. Subversion issues • Merging hell • Fear of breaking the build • delayed commits lead to more merging hell
- 20. Subversion issues • Merging hell • Fear of breaking the build • delayed commits lead to more merging hell
- 21. Subversion issues • Merging hell • Fear of breaking the build • delayed commits lead to more merging hell
- 22. Rise of DVCS • High adoption in Open Source projects • Enterprises now making the move • Atlassian teams already migrated
- 23. Rise of DVCS • High adoption in Open Source projects • Enterprises now making the move • Atlassian teams already migrated
- 24. Rise of DVCS • High adoption in Open Source projects • Enterprises now making the move • Atlassian teams already migrated
- 25. Everyone is doing it!
- 26. Everyone is doing it!
- 27. Social coding
- 28. Social coding
- 29. Social coding
- 31. Enhancing the development cycle with DVCS
- 33. Distributed Version Control Git or Mercurial Git or Mercurial Git or Mercurial Git or Mercurial Git or Mercurial Git or Mercurial
- 34. DVCS encourages learning • Smaller projects • Smaller iterations / continuous deployment • Faster feedback • Greater collaboration & innovation • Understanding customers better
- 35. What do I need to learn
- 36. What do I need to learn
- 38. Not just the command line
- 39. Not just the command line
- 40. Not just the command line The command line is like Marmite...
- 41. “ Distributed Version Control is flexible and can fit any ” workflow - you can even treat it like Subversion.
- 42. “ Distributed Version Control is flexible and can fit any ” workflow - you can even treat it like Subversion. Steve Streeting Creator of SourceTree
- 45. How did Atlassian do it? Recipe for DVCS adoption
- 46. How did Atlassian do it? Recipe for DVCS adoption
- 48. Atlassian DVCS recipe Tooling
- 49. Git and Mercurial Mac Client
- 50. Git and Mercurial Mac Client
- 51. Browse and Search source across versioning tools Commits to SVN & DVCS repos Browse source in Subversion, Git, Hg, CVS, etc.
- 52. Browse and Search source across versioning tools Commits to SVN & DVCS repos Browse source in Subversion, Git, Hg, CVS, etc.
- 55. Continuous Integration and release management • Run same builds against old and new VCS • Continuous Validation • Separate repos for integration
- 56. Continuous Integration and release management • Run same builds against old and new VCS • Continuous Validation • Separate repos for integration
- 57. Link every commit to JIRA issues
- 58. Link every commit to JIRA issues
- 60. Atlassian DVCS recipe Practices
- 61. Incremental change • Try on small projects • Use hybrid tooling
- 62. Bringing our history with us
- 63. Bringing our history with us
- 65. Atlassian DVCS recipe Experience
- 66. DVCS mentor
- 67. DVCS mentor
- 68. DVCS mentor
- 69. Code without Limitations • Fork & Clone • Repositories are cheap, don't be afraid to mess up
- 72. Atlassian DVCS
- 73. Atlassian DVCS Benefits
- 74. Benefit: Developer Speed • Common commands, just faster • Fast tools = happy developers • Complete history at hand
- 75. Benefit: Developer Speed • Common commands, just faster • Fast tools = happy developers • Complete history at hand
- 76. Benefit: Fast Feedback • More lessons learnt • Issues resolved more timely • Less risk and impact to a project • More in tune with customers
- 77. Benefit: Fast Feedback • More lessons learnt • Issues resolved more timely • Less risk and impact to a project • More in tune with customers
- 78. DVCS @ Atlassian
- 79. DVCS @ Atlassian
- 80. Wrap up • DVCS has great business and technical benefits • Atlassian is shaping the future of DVCS
- 81. Thank you blogs.atlassian.com sourcetreeapp.com blog.jr0cket.co.uk @jr0cket
Hinweis der Redaktion
- Welcome to Unite, I hope you are enjoying the day so far...\n
- Why am talking about DVCS and what is that anyway?\n\n[Opportunity to ask people who they are (developers of any kind) and if they have heard of DVCS. If there are more than a handful of devs, then ask if they are using Subversion, Git, Mercurial, anything else?]\n\n\n
- \n
- JIRA is versioning tool for your issues - you can see the history of the issue and who got involved with that issue.\n
- Confluence is a versioning tool for your collaborative content.\n\nThese are important changes to manage, but they are relatively simple to manage, working with code is usually more complex.\n\n\n
- Now we are supporting developers directly and helping shape the future of code versioning with Bitbucket and SourceTree, a great pair of DVCS tools to help developers get work done.\n\nUsing these tools we improve the way developers manage all the changes around all of the projects they work on, from code, configurations, web artifacts, images, etc.\n\nI hope to show that using DVCS for your versioning provides real business benefit to your organisation and makes your developers happy nerds.\n
- We want to share our experience of our move to DVCS\n- talking about why we did it, \n- how we did it and \n- what benefits we got from it.\n\n[Quick slide to make sure people are settled and know what they are about to hear]\n
- Version control is a safe place to keep your code and other important scripts and configuration files, so you can manage them safely...\n\n\n
- - A place where the team can work together\nEverybody can work on the same code base and get changes from other team mates\n\n- Time Machine\nYou can go back in time - if you want the code base of an older version, you can get it out of the version control system.\n\n- Make duplicates\nMaking a copy of the code and work on that\n
- - A place where the team can work together\nEverybody can work on the same code base and get changes from other team mates\n\n- Time Machine\nYou can go back in time - if you want the code base of an older version, you can get it out of the version control system.\n\n- Make duplicates\nMaking a copy of the code and work on that\n
- - A place where the team can work together\nEverybody can work on the same code base and get changes from other team mates\n\n- Time Machine\nYou can go back in time - if you want the code base of an older version, you can get it out of the version control system.\n\n- Make duplicates\nMaking a copy of the code and work on that\n
- - A place where the team can work together\nEverybody can work on the same code base and get changes from other team mates\n\n- Time Machine\nYou can go back in time - if you want the code base of an older version, you can get it out of the version control system.\n\n- Make duplicates\nMaking a copy of the code and work on that\n
- - A place where the team can work together\nEverybody can work on the same code base and get changes from other team mates\n\n- Time Machine\nYou can go back in time - if you want the code base of an older version, you can get it out of the version control system.\n\n- Make duplicates\nMaking a copy of the code and work on that\n
- - A place where the team can work together\nEverybody can work on the same code base and get changes from other team mates\n\n- Time Machine\nYou can go back in time - if you want the code base of an older version, you can get it out of the version control system.\n\n- Make duplicates\nMaking a copy of the code and work on that\n
- - A place where the team can work together\nEverybody can work on the same code base and get changes from other team mates\n\n- Time Machine\nYou can go back in time - if you want the code base of an older version, you can get it out of the version control system.\n\n- Make duplicates\nMaking a copy of the code and work on that\n
- It used to be the case that all new projects in the Enterprise and open source world were started with subversion.\n\nYes there were (still are) a few die hards still using CVS, but the defacto standard was Subversion.\n\nThere were many reasons for the popularity:\n- it fixed a lot of flaws with CVS (the previous defacto version control system)\n- it was easy to learn as it had the same file based versioning mindset\n- it was easy to set up a repository with access over a secure Internet connection\n- services like sourceforge provided open source projects with all the subversion servers they could want\n\n
- Using Beef as a more colourful term for problem, to follow the UK theme of changing the guards (beefeaters)\n\n\n
- With a centralised server, everyone shares the same resource. Its like going to a all you can eat buffet, anyone can go up to buffet at any time and make a change, but if two people want the last slice of peperoni pizza you have a conflict.\n\nIts not quite that bad for developers (we seem to have a never ending supply of pizza)\n\nIf two developers make a changes to the same part of the code they could create a conflict when they both attempt to save those changes back to the repository. The bigger they changes they make, the more risk of conflict they have with changes from one or more other developers.\n\nUsing a central model is how Atlassian teams used to work and it could make us all very angry nerds some times.\n\n\n
- Angry nerds....\n
- Subversion is still used by a lot of developers, even though they regularly have issues with merging all the code together from each developer. As subversion only understands changes to individual files, it takes a lot of communication for a development team to not stand on each others toes when working on the same product.\n\nWhen using subversion, you have one server you connect with to save all your changes. All the changes have to be in sync with each other. If two developers work on the same code and want to commit their changes, considerable effort can be involved to merge all these changes into subversion.\n\nWhen you also have a continuous integration server attached to your subversion server, developers can become concerned about breaking the build and often delay checkin in code, making it harder to merge all these changes together.\n\nUsing DVCS, you encourage developers to commit their changes constantly.\n\n
- Subversion is still used by a lot of developers, even though they regularly have issues with merging all the code together from each developer. As subversion only understands changes to individual files, it takes a lot of communication for a development team to not stand on each others toes when working on the same product.\n\nWhen using subversion, you have one server you connect with to save all your changes. All the changes have to be in sync with each other. If two developers work on the same code and want to commit their changes, considerable effort can be involved to merge all these changes into subversion.\n\nWhen you also have a continuous integration server attached to your subversion server, developers can become concerned about breaking the build and often delay checkin in code, making it harder to merge all these changes together.\n\nUsing DVCS, you encourage developers to commit their changes constantly.\n\n
- A changing of the guard - UK reference - may want to change this for other countries\n\nOpen source has lead the way for many innovations in the tools development teams use, from the early days of Linux, JUnit framework, Apache Web Server, MySQL, Eclipse / Netbeans, Web Services, NoSQL. The trends in the Open Source community help enterprises understand important technologies. With DVCS being the fastest technology adoption in the community, its sending all the right signals for adoption. \n\nIts no surprise that Enterprise scale organisations like Google, Facebook, Disney and others are making use of Distributed version control tools like Bitbucket and SourceTree to help grow and sustain their business.\n\n\n
- A changing of the guard - UK reference - may want to change this for other countries\n\nOpen source has lead the way for many innovations in the tools development teams use, from the early days of Linux, JUnit framework, Apache Web Server, MySQL, Eclipse / Netbeans, Web Services, NoSQL. The trends in the Open Source community help enterprises understand important technologies. With DVCS being the fastest technology adoption in the community, its sending all the right signals for adoption. \n\nIts no surprise that Enterprise scale organisations like Google, Facebook, Disney and others are making use of Distributed version control tools like Bitbucket and SourceTree to help grow and sustain their business.\n\n\n
- A changing of the guard - UK reference - may want to change this for other countries\n\nOpen source has lead the way for many innovations in the tools development teams use, from the early days of Linux, JUnit framework, Apache Web Server, MySQL, Eclipse / Netbeans, Web Services, NoSQL. The trends in the Open Source community help enterprises understand important technologies. With DVCS being the fastest technology adoption in the community, its sending all the right signals for adoption. \n\nIts no surprise that Enterprise scale organisations like Google, Facebook, Disney and others are making use of Distributed version control tools like Bitbucket and SourceTree to help grow and sustain their business.\n\n\n
- A changing of the guard - UK reference - may want to change this for other countries\n\nOpen source has lead the way for many innovations in the tools development teams use, from the early days of Linux, JUnit framework, Apache Web Server, MySQL, Eclipse / Netbeans, Web Services, NoSQL. The trends in the Open Source community help enterprises understand important technologies. With DVCS being the fastest technology adoption in the community, its sending all the right signals for adoption. \n\nIts no surprise that Enterprise scale organisations like Google, Facebook, Disney and others are making use of Distributed version control tools like Bitbucket and SourceTree to help grow and sustain their business.\n\n\n
- A changing of the guard - UK reference - may want to change this for other countries\n\nOpen source has lead the way for many innovations in the tools development teams use, from the early days of Linux, JUnit framework, Apache Web Server, MySQL, Eclipse / Netbeans, Web Services, NoSQL. The trends in the Open Source community help enterprises understand important technologies. With DVCS being the fastest technology adoption in the community, its sending all the right signals for adoption. \n\nIts no surprise that Enterprise scale organisations like Google, Facebook, Disney and others are making use of Distributed version control tools like Bitbucket and SourceTree to help grow and sustain their business.\n\n\n
- Everyone is either using DVCS or seriously evaluating it\n\n\n
- Everyone is either using DVCS or seriously evaluating it\n\n\n
- Everyone is either using DVCS or seriously evaluating it\n\n\n
- Everyone is either using DVCS or seriously evaluating it\n\n\n
- Everyone is either using DVCS or seriously evaluating it\n\n\n
- DVCS and the rise of services like Bitbucket have helped evolve open source projects to a new level of social coding.\n\nDevelopers across the world can quickly share their code with everyone, anyone can take that code and change it, then send a message to say hey “I found a bug in your code, here is a fix for it”\n\nThis social coding is obviously great for open source project acceleration, as many hands get more work done. This is main reason why so many projects have switched. \n\nFor enterprises this sharing of code supports innovation and promotes collaboration within an organisation. With a private repository from Bitbucket, a team can share their code safely within the organisation and create high quality software products.\n
- DVCS and the rise of services like Bitbucket have helped evolve open source projects to a new level of social coding.\n\nDevelopers across the world can quickly share their code with everyone, anyone can take that code and change it, then send a message to say hey “I found a bug in your code, here is a fix for it”\n\nThis social coding is obviously great for open source project acceleration, as many hands get more work done. This is main reason why so many projects have switched. \n\nFor enterprises this sharing of code supports innovation and promotes collaboration within an organisation. With a private repository from Bitbucket, a team can share their code safely within the organisation and create high quality software products.\n
- \n
- The basics of how we have enhanced the way we develop software at Atlassian.\n\nA slide to just take a quick breath and see how people are doing...\n
- Walk through the main idea of a central server - SVN style. Mention others - CVS, P4, ClearCase\n\nMost people are familiar with the centralized version controls of the world - SVN, P4, CVS\nDescribe centralized versions control with SVN (image of how it works)\nThis what Atlassian was doing across a majority of our product teams teams\n\n\n\n
- Walk through the main idea of a central server - SVN style. Mention others - CVS, P4, ClearCase\n\nMost people are familiar with the centralized version controls of the world - SVN, P4, CVS\nDescribe centralized versions control with SVN (image of how it works)\nThis what Atlassian was doing across a majority of our product teams teams\n\n\nThe P stands for Power - enabling developers...\n\n
- \n
- Instead of one big repository, the common approach is to split your code up into a more modular set of components or plugins - this is the way that Atlassian have been working for a while. In JIRA and Confluence, nearly everything is a plugin, even if it is a core part of the product.\n\nInstead of three month projects (97 days at Atlassian) a two week iteration is now running for development teams, allowing much quicker feedback from the rest of Atlassian. \n\nAs a developer you learn so much more the sooner you get feedback from your code. Code reviews are a great example of this, as are unit tests. However, there is no greater feedback than someone actually using your code day in day out. As we dogfood our products at Atlassian, any new features have over 400 eyes on them a few days after they were written and we can give feedback to the developers whilst they still remember clearly how they created those features.\n\nAn increased feedback cycle spawns more collaboration and innovation throughout Atlassian, as new features lead on to new ideas.\n\n
- Every developer can create a copy of a DVCS repository on their own PC, this is called a clone. The cloned repository has the full history of the original repository and so you can trace back through all the changes that were ever done for that project.\n\nAs we are using change sets to record the change rather than individual file changes, then it is easier to manage many different branches (Forks), especially when using pull requests.\n\nPull requests give an opportunity for code review, integration testing and continuous integration builds to run.\n\n
- The way you work with DVCS commands (for both Git & Mercurial) are very similar to the subversion and CVS commands used. As DVCS has an additional remote repository (usually called the origin in Open Source projects) there is one extra optional step.\n\nIf you do not need to share your whole repository with anyone, there is no need to push your repository to another one.\n\nIf you want to submit a simple change, you can package it up as a pull request - a request to have your specific change pulled into someone elses repository. For example if you fork someones project on Bitbucket, making a copy that has a link back to the original repository, you can make changes to your copy of the code, commit them to your own repository and then create a pull request using the magic button on Bitbucket to send a message back to the owner of the repository. If the owner likes your change, it will be added into their repository and become officially part of the project.\n\n\n
- Previously we showed the commands for git you enter on your operating system command line, you can uses visual tools like SourceTree from Atlassian to manage the whole workflow.\n\nIt seems the command line is like Marmite, you either love it or hate it. [Add your own opinion here if you wish]\n
- Previously we showed the commands for git you enter on your operating system command line, you can uses visual tools like SourceTree from Atlassian to manage the whole workflow.\n\nIt seems the command line is like Marmite, you either love it or hate it. [Add your own opinion here if you wish]\n
- Previously we showed the commands for git you enter on your operating system command line, you can uses visual tools like SourceTree from Atlassian to manage the whole workflow.\n\nIt seems the command line is like Marmite, you either love it or hate it. [Add your own opinion here if you wish]\n
- - You don’t have to use DVCS full power right away\n- Feel safe at home by keeping your workflow\n- Explore the possibilities as you get more familiar with the tool\n\n
- \n
- \n
- \n
- \n
- \n
- The following should be a slide in their own right....\n\n\nBring our history with us. The team wanted the Mercurial repository to resemble it’s Subversion counterpart as much as possible. We wanted to have the all the history contributing to our development branch (trunk) as well as our two supported release branches (2.2 and 2.3 at the time). Other branches such as fedex branches and 20% time were less important but ideally converted as well. We were happy to exclude accidental commits and commits of large files from the conversion.\nTool Integration. We wanted to make sure the tools and software that we used for development provided the same level of integration with Mercurial as they do for Subversion. These were mainly FishEye, Crucible, Bamboo, Eclipse and Intellij IDEA.\nIncremental. The conversion should be performed incrementally. This was incredibly important in order to ensure that the history was how we expected it, system integration worked and everyone could perform their development tasks without running into problems due to Mercurial. This was also important in minimising the disruptions that would occur for developers.\nReplicate team process. At least initially, we wanted to replicate the current Subversion development workflow using Mercurial. We were happy the experiment with other workflows which aren’t possible in subversion after the initial migration.\n\n
- Share the knowledge around the team\n\n\n
- Using SourceTree to help us work with our code in DVCS systems so we don’t have to learn the command line.\n\n
- Using SourceTree to help us work with our code in DVCS systems so we don’t have to learn the command line.\n\n
- \n
- View file history \nView authors/blame - BB or Stash\nSwitching/creating a branch - BB\nListing Tags\n\n
- [Add stuff about crucible and DVCS]\n
- View file history \nView authors/blame - BB or Stash\nSwitching/creating a branch - BB\n\n\n
- View file history \nView authors/blame - BB or Stash\nSwitching/creating a branch - BB\nListing Tags\n\n
- \n
- Show how you write JIRA issue numbers in your commit statements to link up your commits with the issues in JIRA that commit addresses.\n\nThen cover how Crucible uses that JIRA number in commit to help you find the right review\n
- \n
- Share the knowledge around the team\n\n\n
- Using a good tool you can start using the power of DVCS whist still having a subversion repository. Using things like GitSVN you can have local git repos that will push to a subversion.\n\nGive developers a chance to learn the tools well, so you are not slowing down the development process or making it too frustrating.\n\nDVCS is a new skill, so give your teams time to adopt.\n
- Bring as much of the history from Subversion as you can, its an important record of your development.\n\nMake sure code is checked into the subversion, then make it read only\n
- Share the knowledge around the team\n\n\n
- Include a person of experience with DVCS in the team\nThe knowledge and experience spreads round the team\nMove people with DVCD experience around teams\n
- Include a person of experience with DVCS in the team\nThe knowledge and experience spreads round the team\nMove people with DVCD experience around teams\n
- Include a person of experience with DVCS in the team\nThe knowledge and experience spreads round the team\nMove people with DVCD experience around teams\n
- Include a person of experience with DVCS in the team\nThe knowledge and experience spreads round the team\nMove people with DVCD experience around teams\n
- Include a person of experience with DVCS in the team\nThe knowledge and experience spreads round the team\nMove people with DVCD experience around teams\n
- Everything is on your own machine - don’t be afraid to mess up, it is easy to get back into a stage where things are stable.\n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- Be a coding ninja and commit all your changes early and often. Typically you write a failing unit test, then commit. Write some code to pass the tests and then commit. Think about refactoring and the start all over again.\n\nSome developers say the code is the documentation, but the code is just the present. By giving meaningful commit messages anyone can review the code and have a better understanding of how that code evolved.\n
- Be a coding ninja and commit all your changes early and often. Typically you write a failing unit test, then commit. Write some code to pass the tests and then commit. Think about refactoring and the start all over again.\n\nSome developers say the code is the documentation, but the code is just the present. By giving meaningful commit messages anyone can review the code and have a better understanding of how that code evolved.\n
- Share the knowledge around the team\n\n\n
- I got the need, the need for SPEED (we like to drive fast)\n Common commands, just faster - status, log, commit, branch/merge are instantaneous\n The speed with which DVCS carries out common tasks lowers the bar and encourages developers in making use of those procedures. That, in turn, means that teams are using their version control system in more versatile and effective ways.\n Dev history without going over the network\nFast tool = Happy Developers\n No Servers bogging you down - push when you are ready\n Commit often\n Use the features instead of bypassing them bc they are slow\nCode without limitations\n Do "stuff" after the fact\n apply changes to a different branch <cmd>\n need more here....\n Jump between and modify branches\n need more here...\n \nAs stated in the previous slides, common commands become useful again. When commands are instantaneous that are used more often than not. Think back to any fuction in JIRA or Confluence...if they were not easily accesible you may not use them. Same with version control - if they take time or the commands are advanced you may not use the full power of the technology.\n\n\nYou will use the command line as its faster ???\n\n\nExample to give ambassadors context: Working without a network connection to your subversion repository is more than just committing the changes. If you make a mistake in a file or try a spike solution, and want to start over, you can&#x2019;t until the network returns. If you want to diff between previous versions to help find a problem, you can&#x2019;t until the network returns.\n\nDVCS allows you to utilize version control during your development without contaminating the team repository.\n
- Developers have a clearer understanding of the impact of their work, both in the benefits they deliver to the customers and the potential problems if issues should arise.\n\nMore lessons learnt throughout the whole company. Small changes that build on each other are easier to absorb and get meaningful feedback, in a way that a big bang approach does not.\n\nFeeback from customers (dogfooding or OnDemand) make better products as Atlassian has a better understanding of the customer experience.\n
- Naturally, as we use DVCS ourselves, all our products work with DVCS tools.\n
- Naturally, as we use DVCS ourselves, all our products work with DVCS tools.\n
- [A very quick wrap up, just to get people to sign up to Bitbucket for free, for unlimited public or private repositories. Also to download SourceTree for the MacOSX]\n\n- Bitbucket\n- Sourcetree\n- Making the change recipe\n- DVCS microsite\n- Blog series\n- integration with all our tools\n\n
- \n