DOCSLIB.ORG

Our Journey to Devops at Microsoft

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Our Journey to Devops at Microsoft Azure DevOps Randy Pagels Azure Specialist - Application Development US Great Lakes Region How Microsoft Engineering uses Azure DevOps MS Engineering uses 1ES to build Azure DevOps, Windows 10, Visual Studio, Bing…etc. …using Azure DevOps …building 146,000 times per day …deploying 82,000 times per day … for millions of users + most of Microsoft. Microsoft’s DevOps Tooling – enhanced by GitHub Security Package Registry Actions The journey so far Sprint 162 Nov 2019 VSTS Preview 1ES Windows on Git Azure Pipelines Sprint 1 Sprint 29 Sprint 67 Sprint 102 Sprint 140 August 2010 June 2012 June 2014 May 2017 Sep 2018 400 Open Source Projects Microsoft on GitHub VS Code Join Linux GitHub March 2010 July 2014 April 2015 Foundation Acquired Nov 2016 Oct 2018 8.8k open source projects 25k employees contributing Before Azure DevOps Microsoft Confidential One Engineering System (”1ES”) One Engineering System with Azure DevOps Microsoft Confidential 1ES Growth 100,000 80,000 Non-engineering Users 60,000 40,000 Engineer Users 20,000 0 DevOps at Microsoft Azure DevOps is the toolchain of choice for Microsoft engineering with over 110,000 active internal users ➔ https://aka.ms/DevOpsAtMicrosoft 4.6m 28k 442k Builds per month Work items created/day Pull Requests per 155pb 500k month Build artifacts managed Work items updated/day 2.4m Private Git commits per 8.8k 24k 82,000 month Open Source Repos Employees contributing to open source Deployments per day Data: Internal Microsoft engineering system activity, November 2019 One Engineering System with Azure DevOps Azure Networking Microsoft Confidential Software Products 500GB+ 6000+ Source code Repos Microsoft Confidential On Average, Each Month 7,300 Developers making code changes 11,000 Topic branches 367,000 Commits10 commits per minute 33,000 Pull1,100 requests pull requests per day 9,700 Branch Integrations Microsoft Confidential For 1 Day of Automated Lab Testing Customer Obsessed Production First Mindset Team Autonomy + Enterprise Alignment Shift Left Quality Infrastructure as Flexible Resource Customer Obsessed Production First Mindset Team Autonomy + Enterprise Alignment Shift Left Quality Infrastructure as Flexible Resource Quantitively & Qualitatively Customer Usage Acquisition Live Site Health Things we don’t watch Engagement Satisfaction Time to Detect Original estimate Churn Time to Communicate Completed hours Feature Usage Time to Mitigate Lines of Code Which customers affected Team capacity Pipeline Velocity Incident Prevention Items Team burndown Time to Build Aging Prevention Items Team story point velocity Time to Test SLA per Customer # of bugs found Time to Deploy Customer Support Metrics % code coverage Time to Improve Failed and flaky automation Customer Obsessed Production First Mindset Team Autonomy + Enterprise Alignment Shift Left Quality Infrastructure as Flexible Resource • • • • • • • • • • • • • • • • Assume Breach Started with war games to the learn attacks and practice response vs. Initially double-blind test Shifted left to prevent top risks Over time, eliminated blue team Credential theft Our defenders need to be our defenders Secret leakage OSS vulnerabilities Customer Obsessed Production First Mindset Team Autonomy + Enterprise Alignment Shift Left Quality Infrastructure as Flexible Resource “Let’s try to give our teams three things…. Autonomy, Mastery, Purpose” Alignment Autonomy Teams Physical team rooms Cross discipline 10-12 people Self managing Clear charter and goals Intact for 12-18 months Own features in production Own deployment of features UI API Data UI API Data Typically <20% Employee choice, not change, but 100% get Cross-pollinate talent manager driven to make a choice and micro-culture Sticky Note Exercise - Self Forming Teams Leadership is responsible for driving the big picture Sprint Plan Season Strategy 3 weeks 3 sprints 6 months 12 months 1 3 6 Teams are responsible for the detail 3 weeks Spring Fall Spring Fall Customer Obsessed Production First Mindset Team Autonomy + Enterprise Alignment Shift Left Quality Infrastructure as Flexible Resource Managing the pipeline: How do you go fast and not break things? engineers on x = # your team 5 ? 10 x 5 = 50 Rule: If your bug count exceeds your bug cap… stop working on new features until you’re back under the cap. Old way of branching Composing Isolation Mechanisms Release Service Pack Fixes Hot fixes Release Integration/Main Team A Team B Team C Feature 1 Feature 2 Release Flow Using Trunk Based Development to avoid Merge Debt Your aim won’t be perfect. Control the 1 blast radius. Customer Obsessed Production First Mindset Team Autonomy + Enterprise Alignment Shift Left Quality Infrastructure as Flexible Resource One code base with multiple delivery streams Shared abstraction layer Single master branch, multiple release branches Update 2 Azure DevOps Server Update 1 Update N Azure DevOps (SaaS) Before After • 4-6 month milestones • 3-week sprints • Horizontal teams • Vertical teams • Personal offices • Team rooms • Long planning cycles • Continual Planning & Learning • PM, Dev, Test • PM & Engineering • Yearly customer engagement • Continual customer engagement • Feature branches • Everyone in master • 20+ person teams • 8-12 person teams • Secret roadmap • Publicly shared roadmap • Bug debt accumulated • Debt paid as incurred • 100 page spec documents • Mockups in PPT • Private repositories • Inner source • Deep organizational hierarchy • Flattened organization hierarchy • Success is a measure of install numbers • User satisfaction determines success • Features shipped once a year • Features shipped every sprint .
Load more

Recommended publications
  • Azure Devops Server (TFS) Integration with JIRA and Github
    DATASHEET Azure DevOps Server (TFS) Integration with JIRA and GitHub The integration of Azure DevOps Server (TFS) with JIRA and GitHub ensures completely traceability of all workitems in the ecosystem. With this integration, the product management team will have real-time visibility into all defects, commit trends, and commit volume. Integration overview In an Application Lifecycle Management (ALM) ecosystem, the choice of systems and the collaboration between the cross-functional teams play a great role. While the choice of systems impacts the productivity of a team, the cross-functional collaboration helps the teams get complete context of the business requirements. Best-of-breed systems such as Azure DevOps Server (TFS), JIRA, and GitHub bring rich functionalities to the ecosystem. By integrating Azure DevOps Server (TFS), JIRA, and GitHub, the product development team will have real-time visibility into the defects logged by QA team and commits made by the development team. It is also easier for product development team to enforce authentic commits against each work item, and access the changes/edits made to the commits files. How Azure DevOps Server (TFS) - JIRA - GitHub integration is beneficial for an enterprise With Azure DevOps Server (TFS) + JIRA + GitHub integration, enterprises can: Track commit volume, track commit trends and edits/changes to commit files in real time Make better and faster decisions Enforce authentic commits to make sure each commit is Ensure complete traceability of a happening against a scheduled and open workitem ‘requirement’ Eliminate manual effort to close JIRA or Azure DevOps Server (TFS) Meet all compliance requirements workitems by automating the state transition on GitHub commit Ensure quality delivery in stipulated time Leverage the best of functionality and How OpsHub Integration Manager integrates Azure collaboration in the delivery ecosystem DevOps Server (TFS), JIRA, and GitHub OpsHub Integration Manager integrates Azure DevOps Server (TFS), JIRA, and GitHub - all systems with each other bi-directionally.
    [Show full text]
  • Tortoisemerge a Diff/Merge Tool for Windows Version 1.11
    TortoiseMerge A diff/merge tool for Windows Version 1.11 Stefan Küng Lübbe Onken Simon Large TortoiseMerge: A diff/merge tool for Windows: Version 1.11 by Stefan Küng, Lübbe Onken, and Simon Large Publication date 2018/09/22 18:28:22 (r28377) Table of Contents Preface ........................................................................................................................................ vi 1. TortoiseMerge is free! ....................................................................................................... vi 2. Acknowledgments ............................................................................................................. vi 1. Introduction .............................................................................................................................. 1 1.1. Overview ....................................................................................................................... 1 1.2. TortoiseMerge's History .................................................................................................... 1 2. Basic Concepts .......................................................................................................................... 3 2.1. Viewing and Merging Differences ...................................................................................... 3 2.2. Editing Conflicts ............................................................................................................. 3 2.3. Applying Patches ...........................................................................................................
    [Show full text]
  • A Dynamic Software Configuration Management System
    1 A DYNAMIC SOFTWARE CONFIGURATION MANAGEMENT SYSTEM A THESIS SUBMITTED TO THE GRADUATE SCHOOL OF MIDDLE EAST TECHNICAL UNIVERSITY OF MIDDLE EAST TECHNICAL UNIVERSITY BY FATMA GULS¸AH¨ KANDEMIR˙ IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF SCIENCE IN COMPUTER ENGINEERING SEPTEMBER 2012 Approval of the thesis: A DYNAMIC SOFTWARE CONFIGURATION MANAGEMENT SYSTEM submitted by FATMA GULS¸AH¨ KANDEMIR˙ in partial fulfillment of the requirements for the degree of Master of Science in Computer Engineering Department, Middle East Technical Uni- versity by, Prof. Dr. Canan Ozgen¨ Dean, Graduate School of Natural and Applied Sciences Prof. Dr. Adnan Yazıcı Head of Department, Computer Engineering Assoc. Prof. Ali Hikmet Dogru˘ Supervisor, Computer Engineering Dept., METU Dr. Cengiz Erbas¸ Co-supervisor, ASELSAN Examining Committee Members: Assoc. Prof. Ahmet Cos¸ar Computer Engineering Dept., METU Assoc. Prof. Ali Hikmet Dogru˘ Computer Engineering Dept., METU Dr. Cengiz Erbas¸ ASELSAN Assoc. Prof. Pınar S¸enkul Computer Engineering Dept., METU Assoc. Prof. Halit Oguzt˘ uz¨ un¨ Computer Engineering Dept., METU Date: I hereby declare that all information in this document has been obtained and presented in accordance with academic rules and ethical conduct. I also declare that, as required by these rules and conduct, I have fully cited and referenced all material and results that are not original to this work. Name, Last Name: FATMA GULS¸AH¨ KANDEMIR˙ Signature : iii ABSTRACT A DYNAMIC SOFTWARE CONFIGURATION MANAGEMENT SYSTEM Kandemir, Fatma Guls¸ah¨ M.S., Department of Computer Engineering Supervisor : Assoc. Prof. Ali Hikmet Dogru˘ Co-Supervisor : Dr. Cengiz Erbas¸ September 2012, 70 pages Each software project requires a specialized management to handle software development activities throughout the project life cycle successfully and efficiently.
    [Show full text]
  • Software Development Process Improvements - Case QPR Software Plc
    Software development process improvements - Case QPR Software Plc Lidia Zalevskaya Master’s Thesis Degree Programme in Information Systems Management 2019 Abstract Date: 2019.11.24 Author(s) Lidia Zalevskaya Degree programme Information Systems Management, Master’s Degree Thesis title Number of pages and appendix pages Software development process improvements - 98 + 26 Case QPR Software Plc Initially this study was planned as an effort to improve on a software development process within an existing team using an existing product code and systems. However, the situation changed and a new team (DevApps team) was established and given a new project, which created an opportunity to build a new type of team, product, process, and tools pipeline from scratch utilizing the improvement ideas. An Action Research framework was adopted as the theoretical approach for the study, while the Scrum methodology served as a framework for the development practices. The study began by summarizing previously identified problems in the software development process at QPR Software Plc and formulating improvement ideas focused on the coding workflow and Scrum practices. These were then tested in practice by the new DevApps scrum team. The research analysis centres on the process of choosing and setting up the new team’s development tools, figuring out ways of working, and implementing several iterations to find the best suitable development process. The most valuable empirical outcomes were the creation of a branching strategy and Git workflow for the DevApps team, the team members’ practical experience of working with Git and with the Azure DevOps developer services. A key outcome was the shift in many verification activities to earlier phases.
    [Show full text]
  • Create a Pull Request in Bitbucket
    Create A Pull Request In Bitbucket Waverley is unprofitably bombastic after longsome Joshuah swings his bentwood bounteously. Despiteous Hartwell fathomsbroaches forcibly. his advancements institutionalized growlingly. Barmiest Heywood scandalize some dulocracy after tacit Peyter From an effect is your own pull remote repo bitbucket create the event handler, the bitbucket opens the destination branch for a request, if i am facing is Let your pet see their branches, commit messages, and pull requests in context with their Jira issues. You listen also should the Commits tab at the top gave a skill request please see which commits are included, which provide helpful for reviewing big pull requests. Keep every team account to scramble with things, like tablet that pull then got approved, when the build finished, and negotiate more. Learn the basics of submitting a on request, merging, and more. Now we made ready just send me pull time from our seven branch. Awesome bitbucket cloud servers are some nifty solutions when pull request a pull. However, that story ids will show in the grasp on all specified stories. Workzone can move the trust request automatically when appropriate or a percentage of reviewers have approved andor on successful build results. To cost up the webhook and other integration parameters, you need two set although some options in Collaborator and in Bitbucket. Go ahead but add a quote into your choosing. If you delete your fork do you make a saw, the receiver can still decline your request ask the repository to pull back is gone. Many teams use Jira as the final source to truth of project management.
    [Show full text]
  • Azure SQL Dev Training Plans
    Complete Practical; Real-time Job Oriented Training Azure SQL Dev Training Plans PLAN A PLAN B PLAN C Course Details Azure SQL Dev SQL Server SQL Dev Azure SQL Dev Azure SQL Dev Azure DevOps Course Curriculum Chapters 21 to 30 Chapters 1 to 30 Chapters 1 to 48 SQL Basics and Query Writing X SQL DB Design, Table Design X Normal Forms, Joins and Queries X Stored Procedures, UDF, Triggers X Advanced Stored Procedures, TVP X CTE, XML, Triggers, PIVOT, Cursors X Dynamic T-SQL Programming X Real-time Project [Banking] X In-depth Query Tuning, Exec” Plans Index Management , Tuning Tools Locks, Deadlocks, Isolation Levels MCSA Certification Exam - 70 761 Azure SQL Database Dev with T-SQL Azure Database Migrations, DTU Elastic Query Processing, Shard Maps MCSA Certification Exam - 70 762 SDLC, Dev & Operations, DevOps X X DevOps Tools, Git & GitHub X X Docker, Kubernetes, AzureDevOps X X Azure Boards, Repos, Tests, Artifacts X X Azure Pipelines (CI, CD), Case Study X X TOTAL DURATION 2 Weeks 6 Weeks 10 Weeks Trainer : Mr. Sai Phanindra T [16+ Yrs of Real-time Exp]. Profile @ linkedin.com/in/saiphanindra www.sqlschool.com For Free Demo: Reach us on +91 9666 44 0801 or +1 956.825.0401 (24x7) Azure SQL Developer Training Module Duration Plan A Plan B Plan C Module 1 SQL Server, T-SQL Programming, Project 4 W X Module 2 Query Tuning, Azure SQL Database Dev 2 W Module 3 Azure DevOps [Service and Server] 4 W X X Total Duration 2 W 6 W 10 W Module 1: SQL, T-SQL, Programming with Stored Procedures Applicable
    [Show full text]
  • Visual Studio 2019 Azure Devops Services Azure Devops Server 2020
    Visual Studio 2019 Azure DevOps Services Azure DevOps Server 2020 Class Requirements and Setup Guide April 2021 Accentient Classroom Training Requirements and Setup Guide Contents Class Setup Requirements ............................................................................................................................................ 3 ADS2020: Administering Azure DevOps Server 2020 ............................................................................................... 3 ALM2020: Application Lifecycle Management Using Azure DevOps Server 2020 ................................................... 3 AQATP: Assuring Quality Using Azure Test Plans ..................................................................................................... 3 CDADS: Continuous Delivery Using Azure DevOps Services (formerly CDVSTS) ...................................................... 3 MARS: Mastering Azure Repos ................................................................................................................................. 4 MPVS2019: Managing Projects Using Visual Studio 2019 and Scrum...................................................................... 4 MPAB: Managing Projects Using Azure Boards (formerly MPVSTS) ........................................................................ 4 PKAB: Practicing Kanban Using Azure Boards .......................................................................................................... 4 APSSD2019: Applying Professional Scrum for Software Development Using Visual
    [Show full text]
  • Simple Version Control of SAS Programs and SAS Data Sets Magnus Mengelbier, Limelogic Ltd, United Kingdom
    Simple Version Control of SAS Programs and SAS Data Sets Magnus Mengelbier, Limelogic Ltd, United Kingdom ABSTRACT SUBVERSION AND LIFE SCIENCES SAS data sets and programs that reside on the local network are most often stored using a simple Subversion can fit very well within Life Sciences and with a tweak here and there, the version and file system with no capability of version control, audit trail of changes and all the benefits. We revision control can be a foundation for a standard and compliant analytics environment and consider the possibility to capitalise on the capabilities of Subversion and other simple process. straightforward conventions to provide version control and an audit trail for SAS data sets, standard macro libraries and programs without changing the SAS environment. TRUNK –BRANCHES –TAGS OR DEV –QC -PROD INTRODUCTION The approach with trunk, branches and tags can also be used within reporting clinical trials, if outputs are standardized for a specific study and used in multiple reporting events. Most organisations will use the benefits of a local network drive, a mounted share or a dedicated SAS server file system to store and archive study data in multiple formats, analytical programs and trunk Pre-lock data and programs for reporting purposes their respective logs, outputs and deliverables. branch Deliverables for a specific reporting event such as Investigator Brochure A manual process is most often implemented to retain versions and snapshots of data, programs (IB), Investigational New Drug (IND), Clinical Study Reports (CSRs), etc and deliverables with varying degrees of success most often. Although not perfect, the process is tag Dry run, Database Lock, Draft Outputs, Final Outputs sufficient to a degree.
    [Show full text]
  • Trunk Based Development
    Trunk Based Development Tony Bjerstedt What are you going to learn? The problem with traditional branching strategies What is Trunk Based Development How does this help How does it work Some tools and techniques About Me Family Guy Photographer Architect & Developer Leader LinkedIn: https://www.linkedin.com/in/tbjerstedt Email: [email protected] Twitter @tbjerstedt LinkedIn Code Kawishiwi Falls, Ely, MN Branches Why Branch To separate development from support Maintain releases separately Release no code before its time “Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly.” – Martin Fowler (Blog article, 2006) https://www.martinfowler.com/articles/continuousIntegration.html Branch Chaos Long lived branches Never ending sprints Code Freezes Merge Day Hell Approaches to Branching Microsoft Recommended: Standard Branch Plan https://www.infoq.com/news/2012/04/Branching-Guide/ Microsoft Recommended Code Promotion Plan https://www.infoq.com/news/2012/04/Branching-Guide/ Gitflow https://fpy.cz/pub/slides/git-workshop/#/step-1 Trunk Based Development https://www.gocd.org/2018/05/30/ci-microservices-feature-toggles-trunk-based-development/
    [Show full text]
  • Build Better Software, Faster by Connecting Servicenow® Devops and Microsoft Azure Devops
    Build better software, faster by connecting ServiceNow® DevOps and Microsoft Azure Benefits DevOps Simplify enterprise DevOps In today's fast-moving business world, DevOps is increasingly becoming the de Extend the power of the Now facto standard for companies that want to rapidly respond to changing customer and market demands and gain a competitive edge. According to a Platform® to speed up software survey by Gartner, 85% of organizations have adopted, or plan to adopt, a more development and deployment agile, product-centric application delivery model,1 which goes hand in hand by reducing time spent on with the DevOps movement. Still, many organizations are struggling to scale administrative tasks. DevOps to realize enterprise value—with siloed data and limited insights across toolchains causing major delivery bottlenecks. Break down silos Even as companies begin to standardize on powerful, end-to-end tools like Fuel collaboration with real- Microsoft Azure DevOps, there’s still a preference for many aspects of work to be time data sync between managed in ServiceNow, including change management. ServiceNow and Microsoft Azure DevOps. Bridge the gap between operations and development Accelerate change and minimize friction between IT operations and Deliver innovation faster development by connecting work in ServiceNow with Microsoft Azure Accelerate product releases by DevOps. ServiceNow DevOps leverages the power of the Now Platform to tie automating change creation, your entire DevOps toolchain together while delivering streamlined reporting, tracking, and approval. actionable insights, and automated control and governance. The seamless integration between tools helps speed software delivery by enabling developers to keep working in Microsoft Azure DevOps while sharing data Gain end-to-end insights for use in ServiceNow workflows.
    [Show full text]
  • Products Supported by Miradore Online's Patch Management
    Technical Reference Products Supported by Miradore Online's Patch Management Last updated: 10/24/2019 Vendor Product Version 7-Zip 7-Zip 7-Zip 3 7-Zip 7-Zip 7-Zip 4 7-Zip 7-Zip 7-Zip 9 7-Zip 7-Zip 7-Zip 15 7-Zip 7-Zip 7-Zip 16 7-Zip 7-Zip 7-Zip 18 7-Zip 7-Zip 7-Zip 19 Acro Software CutePDF Writer CutePDF Writer 3 Adobe Acrobat Acrobat 5 Adobe Acrobat Acrobat 6 Adobe Acrobat Acrobat 7 Adobe Acrobat Acrobat 8 Adobe Acrobat Acrobat 9 Adobe Acrobat Acrobat X Adobe Acrobat Acrobat XI Adobe Acrobat Acrobat DC Adobe Acrobat Acrobat DC 17 Adobe Acrobat Acrobat DC 18 Adobe Acrobat Acrobat DC 19 Adobe Adobe Photoshop Adobe Photoshop 11 Adobe Adobe Photoshop Adobe Photoshop 12 Adobe Adobe Photoshop Adobe Photoshop 13 Adobe Adobe Photoshop Adobe Photoshop 15 Adobe Adobe Photoshop Adobe Photoshop 16 Adobe AIR AIR Adobe AIR AIR 2 Adobe AIR AIR 3 Adobe AIR AIR 4 Adobe AIR AIR 13 Adobe AIR AIR 14 Adobe AIR AIR 15 Adobe AIR AIR 16 Adobe AIR AIR 17 Adobe AIR AIR 18 Adobe AIR AIR 19 Adobe AIR AIR 20 Adobe AIR AIR 21 Adobe AIR AIR 22 Adobe AIR AIR 23 Adobe AIR AIR 24 Adobe AIR AIR 25 Adobe AIR AIR 26 Adobe AIR AIR 27 Adobe AIR AIR 28 Adobe AIR AIR 30 Miradore Technical Reference Adobe AIR AIR 31 Adobe AIR AIR 32 Adobe Bridge Bridge 4 Adobe Bridge Bridge 5 Adobe Creative Cloud Creative Cloud 3 Adobe Creative Cloud Creative Cloud 4 Adobe Digital Editions Digital Editions 1 Adobe Digital Editions Digital Editions 2 Adobe Digital Editions Digital Editions 3 Adobe Digital Editions Digital Editions 4 Adobe Distiller Distiller 5 Adobe Distiller Distiller 6 Adobe
    [Show full text]
  • Rationale-Based Unified Software Engineering Model
    INSTITUT FÜR INFORMATIK DER TECHNISCHEN UNIVERSITÄT MÜNCHEN Forschungs- und Lehreinheit I Angewandte Softwaretechnik Rationale-based Unified Software Engineering Model Timo Wolf Vollständiger Abdruck der von der Fakultät für Informatik der Technischen Universität München zur Erlangung des akademischen Grades eines Doktors der Naturwissenschaften (Dr. rer. nat.) genehmigten Dissertation. Vorsitzender: Univ.-Prof. Dr. Uwe Baumgarten Prüfer der Dissertation: 1. Univ.-Prof. Bernd Bruegge, Ph.D. 2. Univ.-Prof. Dr. Barbara Paech, Ruprecht-Karls Universität Heidelberg Die Dissertation wurde am 11.05.07 bei der Technischen Universität München eingereicht und durch die Fakultät für Informatik am 10.07.07 angenommen. To Eva and Moritz. – T.W. Acknowledgements I want to thank Prof. Bernd Brügge, Ph.D. for his great support, recommen- dations, and visions. This dissertation would not have been possible without him. I thank Prof. Dr. Barbara Paech for the long-term research collaboration. I am grateful to Allen H. Dutoit, Ph.D. who coached me during my research. I am thankful to all my colleagues from the Chair of Applied Software Engineering and in particular to Monika Markl, Helma Schneider, and Uta Weber for the orga- nizational support. I want to thank my wife Eva and my son Moritz who saw me rarely while writing this dissertation. Contents Abstract 7 Conventions 9 1 Introduction 11 1.1 Artifact inconsistencies . 11 1.2 Distributed collaboration . 13 1.3 Goal and approach . 14 2 The RUSE Meta-Model 17 2.1 Requirements . 17 2.2 The Meta-Model . 24 2.2.1 The project data model . 25 2.2.2 The configuration management model .
    [Show full text]