Que nos espera a los ALM Dudes para el 2013?


Published on

¿Qué nos espera a los ALM Dudes para el 2013?

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Tools used for different purposes—working with requirements, specifying architecture, developing code, testing code, and project management—should all be able to work with a common set of interconnected artifacts stored in a common place. As Figure 2 shows, those artifacts can include requirements, design documents, various versions of source code, test cases, statistics about this development project, and more. This kind of integration allows all sorts of useful things: automatically recording code check-ins, associating tests with source code versions, generating historical reports of bug counts, and more. More important, it allows optimizing the entire process. The flow of work is now apparent, and so making that flow as smooth as possible gets easier.When our industry converges on an architecture, it means there’s broad consensus about the best way to do something.For the most part, the first generation of team development tools didn’t take this approach. The vendors have learned from their experience, however, and team-based tools today can provide this broad integration. Microsoft’s Visual Studio Team System, for example, includes specialized tools for architecture, development, testing, and more, all of which rely on Team Foundation Server (TFS) to store the artifacts they work with.
  • Step 1 – clean up the development process, introduce as many agile concepts as possible. Increases team communications, team capability, project repeatability and lowers costs.
  • Step 2 - Improve quality at the beginning, not during or after. Build in quality. You may have success now, and it might work on smaller projects, but as projects grow and become more complex, or change and have additions over time – then tests become crucial to code quality.
  • 3 – Handle requirements in a clever way - at the same time reduce scope creep, and create living documentation. BDD tests in “Cucumber” language (Given / When / Then) format mean that you reduce the chances of miscommunicating a requirement – Cucumber is a DSL – a Domain Specific Language – one that works between users and developers. We use StoryQ internally (see http://storyq.codeplex.com ) though there are many others.
  • 3. As we primarily produce software to run under windows, our developers use GitExtensions http://code.google.com/p/gitextensions/We simply use shared folders and ordinary file access to repositories, rather than implement MSysGit or other more complete full git:// implementations. This works well for us, and means we don’t need to fiddle with keys, Cygwin or Linux.
  • Image source: http://bit.ly/9bUvdC
  • Real life: do things manually and they fall off, automate as much as possible … leads into the next slide
  • Many options, we’ve settled for TeamCity from Jetbrains (makers of Resharper). See: http://www.jetbrains.com/teamcity/Alternatives CruiseControl, TFS, Hudson/Jenkins etc. For a good list to start from, go to: http://en.wikipedia.org/wiki/Continuous_Integration
  • For more info see: http://www.jetbrains.com/teamcity/features/index.html
  • Source: http://www.jetbrains.com/teamcity/features/delayed_commit.html
  • Source: http://www.jetbrains.com/teamcity/features/delayed_commit.html
  • XP guideline of a 10 minute build is reasonable and achievable for most projects. It s worth the effort to streamline and speed up the build – affects developers every time they commit.Provide continuous visibility and feedback: Targeted feedback. Send the right information to the right people at the right time in the right way.
  • Frequent broken builds suggest developers are not running private builds. Development culture and “people issues” are often more difficult to solve than technical issues. But you need to keep the build (relatively) fast so that developers are willing to run private builds. May require trade-off: allow for occasional broken builds in order to avoid expecting developers to run time-consuming or cumbersome build processes.
  • Reduced risk; you eliminate the blind spot of deferred integration Makes bugs dramatically easier to find and remove; If you introduce a bug and detect it quickly it's far easier to fix. Plus, bugs are also cumulative. The more bugs you have, the harder it is to remove each one.Generate deployable software at any time – Removes one of the biggest barriers to frequent deployment
  • Staged build(or build pipeline) – multiple builds done in sequence. First build is triggered by a commit – should be quick (smoke tests/unit tests). Second build runs slower tests/inspections – integration tests, etc.; takes much longer.Parallel builds – can also work well with staged builds. For instance, can split up the secondary build across multiple build processes or machines.Continuous database integration – Automate the database integration. Rebuild your database and test data every time you run a CI build. Database integration artifacts should be stored in the version control system: DDL, DML, config files, etc. Generate the database from build scripts. Automated scripts for database creation, configuration, population Apply continuous testing and continuous inspection against your database(s)
  • Martin Fowler: When I've described this practice to people, I commonly find two reactions: "it can't work (here)" and "doing it won't make much difference".
  • Que nos espera a los ALM Dudes para el 2013?

    1. 1. ¿ALM en el 2013?Bruno Capuano Innovation Manager @elbruno
    2. 2. Bruno Capuano Innovation Manager @elbrunohttp://www.elbruno.co m
    3. 3. Welcome 2013 !!! (con suerte)
    4. 4. Typical ALM challenges
    5. 5. Typical ALM challenges “We don’t have good visibility into project status” “Our teams are not communicating effectively” “Requirements are not sufficiently defined or tracked” “We need lightweight, agile development processes” “Software is not adequately tested” “Cost of maintaining and operating the solution exceeds the business benefit”
    6. 6. At the end …. 
    7. 7. THE WAY WE WORK Must change … ;) And also our tolos … ;)
    8. 8. ALM Tools … must have DevelopmentArchitecture Tool Test Tool Tool Design Documents Source Test Cases Code Requirements Versions Project Stats ProjectRequirements Management Tool Tool Shared Server
    9. 9. Agile, Scrum, Kanban, … etc• If you aren’t using some form of agile development, see what you can use from Scrum, Kanban or XP• Projects become more predictable and repeatable• Project costs will be lowered• Teams will grow in capability• Teams become more responsive to change• Scope is managed• Customers benefit, being delivered a product that is closer to their needs
    10. 10. TFD: Test First DevelopmentTDD:Test Driven Development• Proven to create better solution designs, with less bad coupling = more maintainable code• Provides safeguards when refactoring• 10% more effort now (with TFD/TDD) or 50% more effort later (without TDD)• A suite of tests built up during the life of the project provide valuable feedback when performance testing• Tests may replace most traditional documentation, and provide “living” documentation beside the code
    11. 11. ATDD and BDD• Acceptance Test Driven Development (ATDD) or Behaviour Driven Development (BDD) will sift out the poorly spec’d out user stories, allowing less scope shift and faster development• BDD tests can be automated providing fast response to the team and to users, faster turnaround of work• BDD tests create a common language that everyone can “speak” – users, developers, testers, managers• BDD tests provide living project documentation• BDD can be applied to smaller or larger units of work
    12. 12. Source Control/Version Control• Must be fast and reliable• Must be simple to use• Handy if it is also inexpensive• Wehave adopted GIT – using local repositories as well as a central repository• Git has offline capabilities and works well with peer-to-peer push/pull• eg., desktop local repo <-> USB stick repo <-> laptop
    13. 13. GITCan your source control do this?If not, get Git.Better yet, use GIT with TFS2012.
    14. 14. The Friction:• If done manually: - manual testing gets boring and quality drops off - manual builds can become too much work - source control: varying quality code, 5pm code oops’s - synchronising code libraries: everyone for themselves• Developers cannot easily see how to change if they are too busy fighting fires• Sometimes too close to issues, cannot see that change is needed, or that change is even possible• Managers push for the quick result, usually less tests
    15. 15. The Fix: Continuous Integration• Automate everything you can: - testing, builds, and deployment where possible• Manyways to do this from DIY, open source, to commercial packages.• Any improvement will help• Find the easiest or cheapest, and start there• We have adopted JetBrains TeamCity (free version)• TeamCity has 3 models: free, paid, enterprise• Supports many different build, test and deploy configurations for Java, and .Net
    16. 16. TeamCity integration• Integration with just about everything:• CVS,Subversion, ClearCase, GIT, Perforce, TFS, Mercurial, S ourceSafe, StarTeam …• Ant, Maven 2, IntelliJ IDEA, Nant, MSBuild …• Email, RSS, Jabber, IDE, Windows Tray …• Eclipse, IntelliJ IDEA, Visual Studio …• Junit, testNG, EMMA, Cobertura …• Rake, NuGet, Powershell, Command Line, FxCop, Gradle …
    17. 17. Broken code doesn’t make it intosource control any more
    18. 18. Pre-tested commits
    19. 19. GIT !!!Source Control System del bueno
    20. 20. Local Version Control • Old-school version control like RCSImage stolen from http://progit.org/book/ which is really good, go read it.
    21. 21. Centralized Version Control • This is how Subversion worksImage stolen from http://progit.org/book/ which is really good, go read it.
    22. 22. Distributed Version Control • This is how Git worksImage stolen from http://progit.org/book/ which is really good, go read it.
    23. 23. Why Do I Care?• Because it has been mandated that you care about version control by Prof. Laurendeau• Because you will use version control at every single coding job you get in the real world • If your company doesn’t have version control in place, that’s a huge warning sign• Because it will change the way you think about programming, for the better• Because it stops you from completely screwing yourselves the day before an iteration is due
    24. 24. Installing Git• Let’s install Git and try some things out.• Linux: use your favourite package manager • Ubuntu: aptitude install git• Use the MSysGit installer • http://code.google.com/p/msysgit/
    25. 25. Learning Git • Read Pro Git, it’s excellent and free • http://progit.org/book/ • Git is extraordinarily powerful and you’ll be a better programmer if you take the time to understand it • If in doubt, always use the built in manual • Every git command has a --help flag • e.g. git cherry-pick --helpSeriously go read http://progit.org/book/.
    26. 26. Getting Started• Let’s tell Git our name and email address • It attaches these to any commits we make so people know who to kill for breaking the build an hour before an iteration is due• git config --global user.name “Your Name”• git config --global user.email “you@place.tld” • --global sets the variable for your OS user • --system sets the variable for all users on your machine • Omit the --global and --system flags to set a git config variable for just this repository
    27. 27. Creating a Repository• git init • Creates a local, empty git repository in the folder where the command is run • Creates a .git folder for the guts of the repository • Only one .git folder, at the root of your repository • This is way nicer than creating a new .svn folder for every single subfolder in your repository• We’ll go over how to work with other people on a remote repository soon
    28. 28. Anatomy of a RepositoryImage stolen from http://progit.org/book/ which is really good, go read it.
    29. 29. Anatomy of a Repository• Crazy important! Memorize this! • The working directory consists of the actual files and folders on your machine • The staging area lets you build commits out of snapshots taken of the files and folders in your working directory • The repository maintains a collection and complete hierarchical history of all commits
    30. 30. Oh God, What’s Happening? • git status • Shows you the state of your staging area and of your working directory • git log • Shows a commit history of your repository • git diff • Shows changes between commits, your working directory, the staging area, etc. • git diff --help to learn moreOr you could just go read http://progit.org/book/ and you’ll be an expert.
    31. 31. Adding & Removing Files• git add file • Adds a snapshot of file to your staging area • You can change file and the snapshot will remain as it is• git rm file • Removes the file snapshot from your staging area and deletes file from your working directory• git rm --cached file • Removes the file snapshot from your staging area while keeping file in your working directory intact
    32. 32. .gitignore• Tells Git which files to ignore outright• Uses glob syntax for pattern matching • There’s a decent summary of glob syntax at linux.about.com/library/cmd/blcmdl7_glob.htm• Git adds re-inclusion rules with !pattern • “Include any files matched by pattern, even if they’ve been ignored by a previous pattern.”• There’s a sample .gitignore on the website • Stack Overflow is a good source of .gitignore files
    33. 33. Making Commits • git commit -m “your message” • Creates a commit from the contents of your staging area and adds it to the repository • -m “your message” sets the commit message • Ifwe keep adding commits we get a linked list that represents the history of our repository • gitk --all gives a graphical history of all branches • Leaving out the --all shows just this branchAnd the book at http://progit.org/book/ has a whole bunch more information. Read the damn book!
    34. 34. GitK Screenshot
    35. 35. Branching & Why It Is Awesome• Branching allows us to create a tree of commits instead of a linked list • Merging will let us turn this into a DAG• Easy,painless branching is the most important and powerful feature of Git • Give each new feature its own branch, which can be merged back into the main (master) branch after it’s been completed and is stable
    36. 36. GitK With Branching
    37. 37. Creating Branches• Gitmaintains a pointer to the current checked out branch, called HEAD• git branch newbranch • Creates a new branch starting at the current commit, but does not move the HEAD pointer• git checkout newbranch • Changes HEAD to point to newbranch• Rungit branch then git checkout to create and start working from a new branch • Shortcut: git checkout -b newbranch
    38. 38. Branching Example $ git branch testing $ git checkout testingImages again stolen from http://progit.org/book/ which you should read because it’s good.
    39. 39. Branching Example $ git commit $ git checkout masterImages stolen from http://progit.org/book/
    40. 40. Branching Example $ git commit • At this point, the branch history has diverged • We want to branch for new features and merge them back into the master branch • This makes your life infinitely easierImages once again stolen from http://progit.org/book/
    41. 41. Merge Tools• git config --global merge.tool toolname • Sets the merge tool for your OS user• A mergetool allows you to fix any conflicts that arise from merging two branches• Google will give you a list of merge tools • I use p4merge, it’s hard to go wrong just choosing a random merge tool and using it• git mergetool • Run this command if anything goes wrong with a merge, it’ll allow you to fix things
    42. 42. Merging• git merge branchname • Allows you to take another branch and merge its changes into the currently checked out branch• Git has hyper-intelligent algorithms that track your content, not your files • If you move or rename a file and make changes to it, it will still be detected as the same content
    43. 43. Merging ExampleImage stolen from http://progit.org/book/
    44. 44. Merging ExampleImage stolen from http://progit.org/book/
    45. 45. Branching & Merging in SVN• It’s relevant to see how the approach taken by Git differs from that of terrible legacy systems like SVN• Subversion doesn’t have real branches • A branch is just a copy of your repository in a named folder • SVN has no concept of branch history and therefore cannot determine common ancestry to help with merging• Subversion doesn’t have real merging • The svn merge command should be called svn diff-and-apply-patch because that’s all it does • “If a merge fails, run svn revert and do it by hand.” • There is no way to tell whether a given set of changes were the result of a merge or were just straight edits
    46. 46. Remote Repositories• git remote add reponame url • Adds an external Git repository called name• git fetch reponame • Fetches updated branches from reponame including all updated data • A remote branch shows up as reponame/branchname• Your local information about remote repositories isn’t updated automatically • You need to run git fetch periodically on your remotes to get new branch/commit information
    47. 47. Remote RepositoriesImage stolen from http://progit.org/book/
    48. 48. Pushing• git push reponame branchname • Adds a local branch to a remote Git repository • You need to have write access to the remote repository • Alternatively, merges your local branch into a remote branch of the same name• git push reponame localbranch:remotebranch • Explicit syntax for merging your changes from localbranch into remotebranch• Always fetch and merge before you push • Save yourself grief and error messages
    49. 49. Pulling• git pull reponame branchname • Fetches from reponame then merges the remote branchname into your local branchname• git pull reponame localbranch:remotebranch • Fetches from reponame then merges reponame/remotebranch into localbranch• Syntactic sugar for fetching and merging • Your workflow should be “git pull; git push”
    50. 50. Tracking Branches• git checkout -b branch remote/otherbranch • Gives you a tracking branch that you can work on, that starts where remote/otherbranch is• Trackingbranches are local branches that have a direct relationship to a remote branch • You can just call git push/pull with no arguments and it know which remote branch to change
    51. 51. Cloning a Repository• git clone url • Creates a new local git repository, creates new tracking branches for each branch in the cloned repository, creates and checks out an initial branch that is forked from the remote’s active branch• Watch out if the remote repository doesn’t have any commits yet (really common thing) • Cloning will fail, you need to do git init, git remote add origin url, create an initial commit with some content, then run git push origin master
    52. 52. Continuous Integration
    53. 53. CI – Project Practices Run tests and inspections as part of build • • All tests and inspections must pass • Build automatically upon code commit • Keep the build fast • Want fast feedback; minutes, not hours • Design builds to fail fast • Run tests/inspections that are most likely to fail first • Want to find out about failures as soon as possible • Provide continuous visibility and feedback • Project status dashboard • Continuous feedback devices
    54. 54. CI - Developer Practices• Commit code frequently (at least daily) • Reduces magnitude of changes to be integrated with each build • Reduces likelihood of stale (out-of-sync) code changes • Reduces effort of troubleshooting failures – less has changed• Run private builds before check-in • Execute same set of tests and inspections that CI will • IDE may help here (e.g. PMD or Checkstyle plugin)• Fix broken builds immediately• Don’t commit broken code • Broken code should fail the private build
    55. 55. CI - Benefits• Reduced risk• Reduced manual, repetitive processes• Easier debugging / troubleshooting• Generate deployable software at any time• Better project visibility• Greater confidence in the software
    56. 56. Advanced CI Practices• Staged builds• Parallel and/or distributed build execution• Automated deployment• Dedicated integration build (CI) machine• Continuous database integration
    57. 57. Staged Build Example
    58. 58. Parallel Build ExampleBuild 1 on Machine 1 Build 2 on Machine 2Compilation / Fast Compilation / FastIntrospection Introspection Unit Tests Unit Tests Integration / System Integration / System Tests Tests Functional Tests Functional Tests Overall Pass/Fail Overall Pass/Fail
    59. 59. Parallel Build Example
    60. 60. Continuous Database Integration• Rebuild your database and test data for every build.• Store database artifacts in version control • DDL, DML, config files, etc.• Generate the database from build scripts • Scripts for database creation, configuration, population• Apply continuous testing / inspection against your database(s)• LiquiBase, Rails Migrations
    61. 61. Continuous Integration vs Build Management“Build Management, essentially, aims to produce a set of artifacts that correspond to a specified snapshot of source code, and to be able to hand off those artifacts to third parties outside of development”• UrbanCode - http://www.cmcrossroads.com/pdf/DrawingtheLine.pdf
    62. 62. CI – BM Comparisons Continuous Integration Build ManagementWhat is the purpose? To integrate the latest To provide a definitive set changes and determine of usable artifacts based on current code quality a given code slice in timeWho is the audience? Internal External (non-developer)What are the products? Pass/Fail, Metrics, Code Deployable artifact qualityWhat is the code base? The latest changes Fixed time referenceWho benefits the most? Developers Infrastructure / Support
    63. 63. Questions to Ponder• Who should own the governance for CI? How about for build management?• Shouldsimilar, different, or exactly the same build processes be used for CI and BM?• Whatis needed to verify the quality of the artifact generated by the BM process?
    64. 64. CI Developer Anti-Patterns• Infrequent check-ins• Premature check-ins (failing code)• Ignoring broken builds• Turning off tests to correct builds• Waiting until end of day to commit changes• Inconsistent developer build environments (works on my machine)
    65. 65. CI Tooling Anti-Patterns• Insufficient feedback• Too much (spam) feedback• Underpowered (slow) build machine• Bloated build• Weak builds that never fail (Continuous Ignorance)• UsingScheduled Builds versus building software with every code change• Failing to clean out old artifacts before each buildhttp://www.ibm.com/developerworks/java/library/j-ap11297/index.html
    66. 66. CI - Challenges“CI is not just a technical implementation; it is also an organizational and cultural implementation” – Paul Duvall, Continuous Integration
    67. 67. Challenges – Cultural • Development culture • Not familiar with continuous integration • Ignore failing tests or broken builds • Not checking in code frequently (daily) • Not running tests before check-in • Lack of encouragement for CI practices
    68. 68. Challenges –Personnel/Experience • Lack of expertise • Continuous Integration • CruiseControl / Hudson • Deployment (e.g., WebSphere) • No dedicated resources for CI (anymore) • Made great progress when we did have that.
    69. 69. Challenges – Infrastructure• Obtaining system accounts, disk space, etc. to run CI• Insufficient and constrained environments • Not enough, not always available • Test environments, app servers, databases, etc.
    70. 70. Challenges – TechnicalImplementation• Stuck on outdated technologies • Java 1.4, Tru64, PVCS, VB, VisualC++• Technology stacks • Grails, Java, Struts, etc – all with differing folder structures• Database changes in separate source repo • Database changes in PVCS; main code in CVS• Disparate systems for CI integration • CVS, PVCS, PICCT, QualityCenter, VersionOne, Fortify• Cruise Control / Hudson – learning curve
    71. 71. Challenges – Running Builds• Brittle tests (e.g., data-dependency)• Slow tests or lots of time-consuming tests• Build “noise” • CI build fails for reasons outside developer control (e.g., bug in Hudson or file access issues)• Interactions between builds • “Access denied” and “Cannot delete …” errors on Hudson • Shortcomings of Windows build server
    72. 72. TEAMCITYOtro gran producto de JetBrains
    73. 73. NUGETGestionando paquetes como unos campeones en Visual Studio
    74. 74. What is NuGet?• .NET Package Manager• Original OSS Project Nu now NuGet• Ships with ASP.NET MVC3• OS Managed by Outercurve Foundation hosted on nuget.codeplex.com• 32,000+ Packages• Current version 1.6• Extendable and is a protocol
    75. 75. What is Package Management?• Tools to simplify discovering, obtaining, installing and updating project references.• Eliminate dependency hell.• Similar to Ruby Gems and OpenWrap – http://openwrap.org• Not like a system package manager like, Linux apt-get.• Windows System Package Managers • Chocolatey – http://chocolatey.org • CoApp – http://coapp.org
    76. 76. What is the goal of NuGet?• Promotion of projects and libraries to ensure great software is readily available and usable.• Eliminate discovering, obtaining, and complex configuration as a barrier to entry for leveraging powerful software.• Make Open Source Software ( OSS ) easy as “Add Reference”.• Eliminate dependency hell.• Improve developer experience and productivity.• Leverage Conventions over configuration• Tight integration with Visual Studio IDE and leverage power of PowerShell.
    77. 77. How do I get started?• Recommend installing NuGet Visual Studio Extension, NuGet Command Line and NuGet Explorer http://nuget.codeplex.com• Visit http://nuget.org• Do a one over the NuGet Documentation - http://docs.nuget.org/• Create a new VS 2010 solution or open an existing solution then hack away on the Open Package Manager Console consuming packages• Start small, replacing a few references with NuGet Package References.• Watch Scott Hansleman’s screen casts on NuGet for in depth knowledge ( references section )
    78. 78. NuGet Package Gallery• Official NuGet Package Gallery - http://nuget.org• Provides official community package library.• Publish Packages with a FREE account• Main NuGet Feed for consuming packages• Package Stats – http://stats.nuget.org• NuGet Team Blog - http://blog.nuget.org/• 32,000+ packages
    79. 79. Why Create Own Packages?• Distribute .NET assemblies and dependencies.• Eliminate dependencies from VCS.• Perform complex configuration and setup to ease adoption.• Distribute • JavaScript Libraries • Samples • Scripts• Support Extensions • Extend Package Mgr Console • Extend NuGet Command Line • Extend NuGet Explorer
    80. 80. What makes up a NuGetPackage?• Meta Data• Dependencies• Content • Transforms • Templates• Libs • dlls• Tools • Init.ps1 • Install.ps1 • Uninstall.ps1
    81. 81. Web Start-Up Code• Simple way to enable start-up of your library in Web Apps• WebActivator NuGet library• Replacements of the .NET 4 attributes • [PreApplicationStartMethod] • [PostApplicationStartMethod]• Content • App_Start• Examples • IoC libraries like Ninject and StructureMap • Commmon • $rootnamespace$
    82. 82. Creating NuGet Packages?• Create Manifest • Manual • Command line • Assembly • Visual Studio Project• Create Packages • Manually using command line • NuGet Explorer • Visual Studio Project • Package Manager Console using New-Package • TeamCity
    83. 83. Package Source• NuGet Visual Studio Extension supports multiple Package Sources in hierarchy order.• NuGet Source Options • Nuget.org • Own Local or Network Directories • Local Cache • Own Read Only Server • Own NuGet Gallery • Own NuGet Orchard Gallery• .NET Community Source Options • MyGet.org • NuGetFeed.org • TeamCity
    84. 84. Why host internal NuGetGallery?• Open Source - https://github.com/NuGet/NuGetGallery• Provides full ownership • Publish proprietary internal packages • Publish backups of external packages • Browse able gallery • Manage internal/external packages • Extend or integrate with own requirements• Extending NuGet Gallery • Baseline Feed • Client/Project Feeds • Community Feeds • Enterprise Feeds • Personal Feeds
    85. 85. What about ContinuousIntegration?• No Commit Strategy • Tracking Package Metadata • Package Restoration• TeamCity Pull, Package and Publish Support• Automated Deployment with Octopus • Convention Based • Shipping Application in NuGet Package • Deploying Applications to servers
    86. 86. What is the value to the team,.NET COP, enterprise, client?• Reduce project dependency management. Simplify setup and onboarding. Improving version management.• Promote reuse, standardization, discovery, collaboration regarding packages across all levels of the organization.• Removal of dependencies from VCS saving valuable disk space.• Improves continuous integration process and opens the opportunity or automated deployments with products like Octopus.• Offers extension points with Chocolatey to improve developer experience regarding machine setup and overall maintenance.• Integration with commercial vendor NuGet feeds like DevExpress
    87. 87. VISUAL STUDIO ALM Back to Visual Studio 2012
    88. 88. You already know it … ;)
    89. 89. Referencias• Download and tutorials: • Official GIT site http://msysgit.github.com/ • Git for Windows http://code.google.com/p/msysgit/downloads/list?q=full+installer+official+git • GitHub for Windows http://windows.github.com/ • JetBrains - Team City http://www.jetbrains.com/teamcity/ • Download TeamCity http://www.jetbrains.com/teamcity/download/index.html• Presentations: • Git from Erick Lawless http://bit.ly/VOJgXo • NuGet – FrozenBlocks http://bit.ly/ZfZBfk • Scaling up and bottoming up http://bit.ly/V2sFOz
    90. 90. Bruno Capuano Innovation Manager @elbrunohttp://www.elbruno.co m