Application Lifecycle Management Tools for C++ in Visual Studio 11
•
0 j'aime•706 vues
Application Lifecycle Management (ALM) tools are critical for planning, development, testing, and maintenance of native code bases of every size. Visual Studio Ultimate offers many features for managing a C++ code base efficiently and easily. Come join us and see some of the current shipping features for C++ and get a live sneak preview of the features shipping in the next version of Visual Studio. You might be very surprised at all the new features for native C++ developers!
Recommandé
Recommandé
Contenu connexe
Plus de Microsoft
Plus de Microsoft (20)
Application Lifecycle Management Tools for C++ in Visual Studio 11
- 2. • Static Code Analysis “lint” • Code Understanding callgraph; headers • Unit Testing & Code Coverage
- 4. Dependency Diagrams Architecture Explorer Native Unit Test Framework
- 6. • Static Code Analysis “lint” • Code Understanding callgraph; headers • Unit Testing & Code Coverage
- 20. • Static Code Analysis “lint” • Code Understanding callgraph; headers • Unit Testing & Code Coverage
- 30. • Static Code Analysis “lint” • Code Understanding callgraph; headers • Unit Testing & Code Coverage
- 34. Q&A
- 35. MICROSOFTC++ 2012 PARTICIPATE IN C++ MICROSOFT DEVELOPER DIVISION DEVELOPMENT USER DESIGN RESEARCH RESEARCH SIGN UP ONLINE AT http://bit.ly/cppdeveloper
- 36. Prochaines sessions des Dev Camps 10 février Open Data - Développer des applications riches avec le protocole Open Live Meeting 2012 Data http://msdn.microsoft.com/fr-fr/devcamp 16 février Azure series - Développer des applications sociales sur la plateforme Live Meeting 2012 Windows Azure Téléchargement, ressources et toolkits : RdV sur MSDN 17 février Live Meeting Comprendre le canvas avec Galactic et la librairie three.js 2012 21 février Live Meeting La production automatisée de code avec CodeFluent Entities http://msdn.microsoft.com/fr-fr/ 2012 2 mars Comprendre et mettre en oeuvre le toolkit Azure pour Windows Phone 7, Live Meeting 2012 iOS et Android Les offres à connaître 6 mars 2012 9 mars Live Meeting Nuget et ALM 90 jours d’essai gratuit de Windows Azure Live Meeting Kinect - Bien gérer la vie de son capteur 2012 www.windowsazure.fr 13 mars 2012 Live Meeting Sharepoint series - Automatisation des tests Jusqu’à 35% de réduction sur Visual Studio Pro, avec l’abonnement MSDN 14 mars TFS Health Check - vérifier la bonne santé de votre plateforme de Live Meeting 2012 développement www.visualstudio.fr 15 mars Live Meeting Azure series - Développer pour les téléphones, les tablettes et le cloud 2012 avec Visual Studio 2010 16 mars Applications METRO design - Désossage en règle d'un template METRO Live Meeting 2012 javascript 20 mars Retour d'expérience LightSwitch, Optimisation de l'accès aux données, Live Meeting 2012 Intégration Silverlight 23 mars Live Meeting OAuth - la clé de l'utilisation des réseaux sociaux dans votre application 2012
Notes de l'éditeur
- ALM, or Application Life Management describes the whole process involved in building, shipping and maintaining software.So, as a Developer, you might start the day be checking-out an existing source file from the version-control system. You then edit the file, write some unit tests, and get it working with the help of the debugger to identify and fix problems. You then submit the change to an automated build system that also runs a batch of regression tests – to make sure that this fix did not break any existing functionality.In the afternoon, you may take part in a bug triage – examining all of the bugs reported by extensive tests; or by customers running already-shipped versions of the software; or by customers running an early beta of the new software. You review the bugs, mark their relative priorities, and assign to testers for further diagnosis.Project managers run off custom reports to monitor the status of tasks – that’s to say, work that has to be done as part of developing the product – and reported bugs. They worry about how the project is progressing against where it should be according to plan. They worry about the rates at which bugs are coming in, being resolved, and being closed. They looks at graphs of bug “burn-down” rates, slippages, and surprises – such as new tasks added to the project.Back when software development was more informal, a small project team did all of these activities. But plans might be written on paper and thrown onto a shelf. Bugs might be recorded in a list, in an ASCII text file. New features might be kept in an Excel spreadsheet, updated manually as new bugs were found. A weekly report meant gathering all of the information together from these different sources, and manually constructing a custom document, which the management of the project poured over around a big table.The whole affair was relaxed – but it worked, because the team was small – and frankly, the volume code produced was small.But software development today is a much more serious (and stressful) undertaking. Teams are large – it’s common to have projects with 100 or more Developers working on the same set of source file – half-a-million lines of C++, for example. And there’s pressure to deliver high-quality software fast – to meet deadlines required in a competitive market, in order that the company survives and grows.So the old tools are inefficient. ALM seeks to solve these problems with a solution that centers around TFS – “Team Foundation Server”. This provides a large set of tools, that all work smoothly together, and solve the problems listed in the orange arc – managing the requirements that the project must meetthe day-to-day, or hour-to-hour monitoring and control of the project’s progressversion control – the system that provides a secure store for the project source files and documents. We update it using database transactions – all or nothing updates. It is backed-up every night, or whatever policy you choose. We can see how any source file evolved – should we ever need to track down a rogue checkin and back-it-out. We can create new “branches” to allow development along parallel branches. It discovers, and in most cases, resolves conflicts where two or more Devs change the same file, over the course of the same few days.Test case management – the 100s or 1000s of tests that the software must pass to be considered “good”. These tests cover unit, functional, performance, stress.Build automation – performing full builds of the entire project with different standard options: incremental or full; debug or optimized (what Visual Studio calls “release”)Reporting – a vast range of reports – both routine and “exception”. Examples would be, progress by Devs – they update how many days, or hours, they have worked on each task and whether the time left is still the same as they estimated; bug rates for incoming, resolved and fixed. “burn-down” rates that predict the date the project will be ready to fix. Exception reports such as peformance test number 123 ran more than 5% slower than it did on the last check – with a bug automatically assigned to the owner of that component. The list goes on and on. And these are just the standard reports.What I’ve described so far is all rather abstract. To give a concrete example, let me describe how it works for us – the 3,500 folks working in Microsoft’s “Developer Division”. We all use TFS every day. Developers, testers, program managers, documentation teams. In particular, in my group – we design and build the C++ compiler – which, in turn, is used to build some enormous products inside Microsoft (Windows, SQL Server, Office and so on); as well as millions of applications around the world, written by IT departments within big corporations and ISVs building their own products and services for sale.