How Atlassian made the switch to DVCS
•Télécharger en tant que KEY, PDF•
3 j'aime•758 vues
An updated and condense version of the recipe Atlassian uses to help migrate their teams to DVCS tooling. This presentation was given in a Webinar by Clearvision http://www.clearvision-cm.com/
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
Similaire à How Atlassian made the switch to DVCS
Similaire à How Atlassian made the switch to DVCS (20)
Plus de John Stevenson
Plus de John Stevenson (20)
Dernier
Dernier (20)
How Atlassian made the switch to DVCS
- 1. Making the Switch to DVCS How Atlassian teams moved from centralised to distributed version control John Stevenson Developing the Atlassian UK Community blog.jr0cket.co.uk @jr0cket 1
- 3. Centralised Version Control Subversion
- 4. Centralised Version Control Subversion
- 5. Subversion issues • Long lived branching causing Merging hell • <3 month release cycles painful • Fear of breaking the build • delayed commits lead to more merging hell
- 6. Subversion issues • Long lived branching causing Merging hell • <3 month release cycles painful • Fear of breaking the build • delayed commits lead to more merging hell
- 7. Enhancing the Atlassian development cycle with DVCS
- 9. Atlassian DVCS recipe Practices
- 10. Learn the new workflow
- 11. Incremental change • Try on small projects • Create test environment for tools • Start with git svn
- 12. Bringing our history with us
- 13. Bringing our history with us
- 14. Modularise your repos Break big Subversion projects into smaller DVCS repos Ensure a modular design for your application
- 17. Social coding = cross-team collaboration
- 18. Social coding = cross-team collaboration
- 19. Social coding = cross-team collaboration
- 20. Code without Limitations • Fork & Clone • Repositories are cheap, don't be afraid to mess up
- 22. Sharing DVCS experiences Specialised teams Build team Deployment User Experience (UX) Operations
- 23. Sharing DVCS experiences Specialised teams Build team Deployment User Experience (UX) Operations
- 24. Continuous Deployment verses (Large) Feature Branching
- 25. Confluence team moving to DVCS •2 week iterations •Continuous deployment •http://blogs.atlassian.com/2012/01/ moving-confluence-from-subversion-to- git/
- 26. Git Integration with the build pipeline
- 27. Link commits to JIRA issues
- 28. Link commits to JIRA issues
- 29. Not just the command line
- 30. Not just the command line
- 31. Not just the command line The command line is like Marmite...
- 32. Git and Mercurial Mac Client
- 33. Git and Mercurial Mac Client
- 35. Viewing Changes
- 36. Visualising code
- 37. Enterprise Git repository management Manage your internal repositories •browse recent commits •inspect change history •explore change sets & annotated code Source code accessible by release managers, testers & other team members
- 41. Continuous Integration and release management • Run same builds against subversion and git • Continuous Validation • Separate repos for integration
- 42. Continuous Integration and release management • Run same builds against subversion and git • Continuous Validation • Separate repos for integration
- 43. Separate Repo for Building Collaboration History of changes Multiple copies
- 44. Separate Repo for Building Collaboration History of changes Multiple copies
- 45. Continuous Integration Stages The "Gatekeeper" • Merges changes from your branch into the main line and builds the result. • Successful code is committed and pushed Automated branch detection The "Build Updater" Branch Plans automatically inherit • Merges the main line into the master plan config changes branch, and builds the combined code. • Successful code is committed & pushed to branch, ensuring longer-living branches don't stray far from trunk.
- 46. Branching and auto-merging The "Gatekeeper" • Merges changes from your branch into the main line and builds the result. Automated branch detection • Successful code is committed and pushed Branch Plans automatically inherit master plan config changes The "Build Updater" • Merges the main line into the branch, and builds the combined code. • Successful code is committed & pushed to branch, ensuring longer-living branches don't stray far from trunk.
- 47. Atlassian DVCS
- 48. Atlassian DVCS Benefits
- 49. Benefit: Developer Speed • Common approach, running faster • Fast tools = happy developers • Complete history at hand
- 50. Benefit: Developer Speed • Common approach, running faster • Fast tools = happy developers • Complete history at hand
- 51. Benefit: Fast Feedback • More lessons learnt • Issues resolved more timely • Less risk and impact to a project • More in tune with customers
- 52. Benefit: Fast Feedback • More lessons learnt • Issues resolved more timely • Less risk and impact to a project • More in tune with customers
- 53. Shaping the future of DVCS
- 54. Thank you blogs.atlassian.com sourcetreeapp.com blog.jr0cket.co.uk @jr0cket
Notes de l'éditeur
- 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
- 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
- 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
- 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
- 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
- Share the knowledge around the team\n\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
- 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
- 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
- \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
- 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 &#x201C;I found a bug in your code, here is a fix for it&#x201D;\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 &#x201C;I found a bug in your code, here is a fix for it&#x201D;\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
- Everything is on your own machine - don&#x2019;t be afraid to mess up, it is easy to get back into a stage where things are stable.\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
- 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
- \n
- Naturally, as we use DVCS ourselves, all our products work with DVCS tools.\n
- Share the knowledge around the team\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
- 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
- Using SourceTree to help us work with our code in DVCS systems so we don&#x2019;t have to learn the command line.\n\n
- Using SourceTree to help us work with our code in DVCS systems so we don&#x2019;t have to learn the command line.\n\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
- 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
- [Add stuff about crucible and DVCS]\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
- \n
- \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
- 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
- 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
- \n