Improving SW Quality Distributed Environment
•Transferir como PPTX, PDF•
1 gostou•441 visualizações
Atlassian ALM MeetUp Stockholm, 28th Nov 2013, Tomi Kallio's presentation about distributed software development topics including Distributed development , Distributed version control, Effective code reviews, Continuous integration, Continuous delivery and Continuous deployment.
Recomendados
Recomendados
Mais conteúdo relacionado
Destaque
Destaque (15)
Semelhante a Improving SW Quality Distributed Environment
Semelhante a Improving SW Quality Distributed Environment (20)
Último
Último (20)
Improving SW Quality Distributed Environment
- 2. Improving SW Quality in a Distributed Environment November 28, 2013 www.ambientia.net 2
- 3. Distributed development ”we can make it faster and cheaper” Distributed version control “branching is good” Effective code reviews “many pairs of eyes” Continuous integration “keeping up with the mainline” bonus Continuous delivery “all the way, all the time” November 28, 2013 www.ambientia.net 3
- 4. Distributed development ”we can make it faster and cheaper” November 28, 2013 www.ambientia.net 4
- 5. Parallel projects Collaborative Remote work Fully internal Virtual teams Open source Geographical distribution Find the best talent available Projects of all sizes Small Large Distributed development ”we can make it faster and cheaper” Stay on top of things Make it easier Who? Invest in tooling What? It can work well! November 28, 2013 FishEye Where? www.ambientia.net 5
- 6. How many of you do distributed development? Any benefits, issues, lessons learnt to share? November 28, 2013 www.ambientia.net 6
- 7. Distributed version control “branching is good” November 28, 2013 www.ambientia.net 7
- 8. Branching made easy Flexibility Branch Independence Repository Safety Isolation Branching model Speed Distributed version control “branching is good” Bookmarks Mercurial Bazaar Git Atlassian Light-weight branches November 28, 2013 FishEye Bitbucket Crucible Stash www.ambientia.net 8
- 9. Do you use distributed version control in your projects? What kind of experiences do you have? November 28, 2013 www.ambientia.net 9
- 10. Effective code reviews “many pairs of eyes” November 28, 2013 www.ambientia.net 10
- 11. Review practices Not all at once Start small Seamless Everything Learn Daily routine Design Share Painless Fast Fluent Security Mentor Quality, overall Effective code reviews “many pairs of eyes” Cheap Commit Informal Formal Effective Patch Stash Developer-driven November 28, 2013 www.ambientia.net Distributed Snippets Audit trail Crucible Version Actions to JIRA 11
- 12. Do you have well established code review practices? How often does the code get reviewed? Are the reviews cost-effective? November 28, 2013 www.ambientia.net 12
- 13. Continuous integration “keeping up with the mainline” November 28, 2013 www.ambientia.net 13
- 14. Repeatable ci cycle Edit Build Fast Automated Test Frequent Visible Deploy Continuous integration “keeping up with the mainline” Branch detection Static analysis Small delta Layered Tests Bamboo Jenkins Feedback Safety net November 28, 2013 Executable specification www.ambientia.net 14
- 15. What is your level of automation? How fast is your edit-build-test cycle? Do you rely on your system? November 28, 2013 www.ambientia.net 15
- 16. bonus Continuous delivery “all the way, all the time” November 28, 2013 www.ambientia.net 16
- 17. Automation Staging Production (again) 1 2 4 … N projects Deploy Scalability Rollback Development N … M environments Deploy gradually bonus Continuous delivery “all the way, all the time” Bamboo environments “Which version is live in production?” JIRA issues “What does project X’s staging environment contain?” November 28, 2013 www.ambientia.net 17
- 18. How often do you deploy? Can you deploy automatically? Are your deploys tracked? November 28, 2013 www.ambientia.net 18
- 19. Tomi Kallio Tel: +358 40 749 2051 Email: tomi.kallio@ambientia.fi Twitter: @tomi_kallio
Notas do Editor
- Application Lifecycle Management (ALM)is about making things betterBeing traceable and transparent, predictable and always on timeIncreasing the efficiencyBecoming more agile, embracing and expecting changeOverall ALM business goals are toImprove the quality of both the sw and also of the operationsNot only the final product but how things are madeBecome more profitable, as an outcome from all of the above
- This discussion track is centered around distributed software development; what experiences we (You!) have, what kind of things are involved, and how to make things better. Raise questions, provide comments and be active. Suggest working practices and tools and procedures that work for you and your teams.We will cover a few main topics with me shortly presenting the topic and then all of us discussing it.
- There are these five main topics to discuss.Less about JIRA and Confluence, or about any particular tools. More about the concepts themselves.We can do less or more depending on your interests.If one particular topic seems to be more interesting to the audience than the others, we could spend most of our time there. Let’s see where the discussion leads us.Topics are presented on their own slides with some key ideas and pointers listed on the slides to get the discussion going.Unstructured – well, you will soon find out what I mean : - )
- We begin with distributed development.This idea that we can do bigger, better, faster, and more if we do many things in parallel.
- Is there something else than distributed development anymore?Distributed development, strictly defined, does not contain subcontracting, outsourcing or virtual teams. We don’t need to limit ourselves with that definition in this discussion. Our aim is to talk about situations where people are doing at least some their work outside of the office environment, detached from their team.For example:When teams and team members are distributed geographically (different room, building, continent and time zone)Development is distributed when there are multiple parallel projects individual developers are contributing to (distribution of their effort)Required special kind of care and tool support.Even when people do remote work it means that the team is distributed, at least some of the time.Yahoo! banned remote work altoghether earlier this year. A bit mistake if you ask me.There are huge distributed development projects, and then there are really small ones. Distribution is common.I personally have been managing a small team distributed globally. One or more people on several continents and time zones.Internal to one company, different teams or organizations working towards a common goal (dependencies).Done in collaboration with other companies, subcontracting or partnering.And, of course, open source projects from small to extremely large ones like the Linux kernel.Recruiting the best talent could mean being forced to be distributed. Some companies and individuals can still thrive.By investing in tooling, challenges of distribution can be tackled.Make things easier for people, especially for your developers.Same weekly, daily, hourly facts available to everybody as soon as possible.Communication and making things visual matters a lot. Natural communication paths are broken; no coffee room discussions.Things can work well even when distributed – just think about success of the Linux kernel development.The tools can make it easy to stay on top of things, all the different activities going on around the whole.Who is working on what and where?What is changing and what should happen nextFor example, AtlassianFishEye can bring activity streams to the developers’ reach. Follow a number of projects, code repositories, files, people, etc.
- Branch is a central concept in distributed version control.Branching and merging has been done well and are central parts of the daily work.Convenience and speed of operations (network optimized).Mostly locally available information.Independence; disconnected operation even when no network is available.Allows contributions without repository access rights, e.g. patches via email or as a pull request.Flexibility in selecting the model. E.g. a web of trust (central integrators) , old central repository model, etc.Isolation; make features (maybe new idea exploration) available to the others at the right time.Safety; every working copy is a full backup.Branching model should be documented and visualized.Everyone needs to know how the system operates.Who accepts patches, which release and feature branches are used.When to fork, where to fork from, when to merge, where to merge back to.Especially important when there are a large number of contributors or participants or when there are many projects to contribute to.Mercurial (bookmarks). Git (light-weight branches). Bazaar.Atlassian provides many tools that can help with maintaining a distributed version control system.FishEye to follow activity streams and to keep in control of things when a lot is happening, Crucible to do code reviews (more about that in a later slide).Stash to manage Git repositories, e.g. one project can have multiple Git repositories.Atlassian is putting a lot of effort into Stash.Development and code reviews in the form of pull requests.Bitbucket online service to manage shared Mercurial and Git repositories. Open source–like model.
- Code reviews can be more effective to catch bugs than tests are. Reviews also happen earlier in the project lifecycle when issues are cheaper to fix.Try to review everything but don’t try to do everything at once.Start with something small, e.g. reviewing all new commits (to a particular part of the system).Grow the reviewed code base incrementally.Learn as you go; become more efficient in understanding where and when to review.Gradually build up knowledge and know-how. Let the senior developers guide the more junior ones.Reviews are a great way to share knowledge.Reviewing a unknown part of a system makes the reviewer to become more familiar with it.Organizing reviews and mentoring other people by being available and running through the main ideas and building blocks.Reviews can be specially targeted, e.g. to find certain type of security issues or to validate early designs before too much code has been contributed.Reviews should become a daily routine for the developers.The practices should be well communicated so people know what is being expected of them.Review frequently; so things can move fast. There should not be a large number of reviews pending. Commit to it!Fluent, seamless; part of the daily flow. Not time away from something “more important”.Painless, make it easy for the reviewers and they will follow.There are many ways to do code reviews, some more formal than others, and more expensive than others.Even quick-and-dirty reviews could be valuable at the very beginning. You look at my code and I’ll look at yours.Depends on the type of the product; nuclear power plant vs. a photo sharing site.Small can be cheap but still very valuable.Think about the parts of the system that would benefit most from reviews.Let the developers be in control so they keep on doing it. Let them define the tooling to use, the processes that best fit their particular projects.Atlassian offers Crucible as the review tool which integrates nicely to FishEye and JIRA.Team can select the right granularity level for reviews.Every commit, eventually everything will get reviewed.Code snippets, “I want early feedback on my approach”.Against a JIRA version (all changes committed to that particular version) or issue.Reviews leave an audit trail; what has been commented, what issues were found.Crucible can make review findings as issues in JIRA. This ensures important findings are not lost.With Stash, one can review pull requests.Several commits at once; independent change sets, e.g. “feature X” or “fix Y”.Review in a way that feels natural to you and your team.
- Code reviews can be more effective to catch bugs than tests are. Reviews also happen earlier in the project lifecycle when issues are cheaper to fix.Review targets:Early designs or approaches.Security issues, especially.Quality, overall.Try to review everything but don’t try to do everything at once.Start with something small, e.g. reviewing all new commits (to a particular part of the system).Grow the reviewed code base incrementally.Learn as you go; become more efficient in understanding where and when to review.Every pull request.Gradually build up knowledge and know-how. Let the senior developers guide the more junior ones.Reviews are a great way to share knowledge.Reviewing a unknown part of a system makes the reviewer to become more familiar with it.Organizing reviews and mentoring other people by being available and running through the main ideas and building blocks.Reviews should become a daily routine for the developers.The practices should be well communicated so people know what is being expected of them.Review frequently; so things can move fast. There should not be a large number of reviews pending. Commit to it!Fluent, seamless; part of the daily flow. Not time away from something “more important”.Painless, make it easy for the reviewers and they will follow.There are many ways to do code reviews, some more formal than others, and more expensive than others.Even quick-and-dirty reviews could be valuable at the very beginning. You look at my code and I’ll look at yours.Depends on the type of the product; nuclear power plant vs. a photo sharing site.Small can be cheap but still very valuable.Think about the parts of the system that would benefit most from reviews.Let the developers be in control so they keep on doing it. Let them define the tooling to use, the processes that best fit their particular projects.Atlassian tools, Stash for DVCS, FishEye+Crucible for traditional VC.A lot of emphasis has been put on Stash lately.Atlassian offers Crucible as the review tool which integrates nicely to FishEye and JIRA.Team can select the right granularity level for reviews.Every commit, eventually everything will get reviewed.Code snippets, “I want early feedback on my approach”.Against a JIRA version (all changes committed to that particular version) or issue.Reviews leave an audit trail; what has been commented, what issues were found.Crucible can make review findings as issues in JIRA. This ensures important findings are not lost.With Stash, one can review pull requests.Several commits at once; independent change sets, e.g. “feature X” or “fix Y”.Incrementally building up the feature by appending to the pull request.Review in a way that feels natural to you and your team.
- Continuous integration means committing changes into the mainline of development as often as feasible.Everybody works more or less on the same set of sources. No major integration issues close to the release date.Developers edit code, commit into the change control system. Continuous integration system detects code changes and executes a series of actions.Actions build and package the code and execute tests (or test-like checks).The edit – build – test cycle is executed all the time, whenever code changes are detected. Delta between commits remains very small.Small deltas reduce the amount of risk.When issues arise, small delta makes it easier and faster to pinpoint what went wrong and do corrective actions.Provide fast feedback to the developers; fail early. Act as a safety net.People should be encouraged to make changes.Can be layered – very fast sanity checks could be executed first. Then more thorough and time consuming tests and other automation.Tests can be thought of as executable specifications. Very many things can be checked with automation.Automation is key.Repeatable processes. Newcomers could commit code on their first day at work.Fast to execute. Execute frequently with ease.Scalability as the number of projects grows and there are more people in each project.START SMALL here as well. Add small checks and automations whenever there is time.Make things visible.Be very clear when things break.Try to find ways to detect what went wrong and bring the information to the developer.Automate releasing as well so that it happens the same way every time.Release decision can still be made manually.Everybody can release.Open source Jenkins is a very commonly used CI tool.Atlassian provides Bamboo which integrates into the other Atlassian tools and makes it easier to follow status and progress across systems.Bamboo can detect new feature branches and start CI for them automatically.
- Web application point of view.Build on the continuous integration system, extending it to deploy to the relevant environments.First, do rigorous testing and quality assurance.Everything should work like in the live production system.Production system for live environment.The decision to go live to production can be manual.The idea of continuous delivery is to all the time verify that the deployment can be done.To keep the system in such a good shape that it is always ready to be deployed to production.Deploying all the changes to production automatically is called Continuous Deployment.With a large number of parallel projects, the number of environments can grow quite large.Each project has multiple environments. There can also be different versions of the same product online at the same time.Again, automation will be of great help here.Need to find out what is live and where.Bamboo Environments can display what is live and where at any given moment. If Bamboo is linked to JIRA, the exact contents of the build (JIRA issues source code commits) can be found.Traceability.Deployment to production systems can be done gradually.Taking systems in partial use for a smaller subset of the user base.Rollback procedures are important.There are large systems in use that do continuous delivery, and even continuous deployment.