DOCSLIB.ORG

Conan Documentation Release 1.25.2

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Conan Documentation Release 1.25.2 Conan Documentation Release 1.25.2 The Conan team Sep 24, 2021 CONTENTS 1 Introduction 3 1.1 Open Source...............................................3 1.2 Decentralized package manager.....................................3 1.3 Binary management...........................................4 1.4 All platforms, all build systems and compilers.............................5 1.5 Stable...................................................5 1.6 Community................................................6 2 Install 7 2.1 Install with pip (recommended).....................................7 2.2 Install from brew (OSX).........................................8 2.3 Install from AUR (Arch Linux).....................................8 2.4 Install the binaries............................................8 2.5 Initial configuration...........................................9 2.6 Install from source............................................9 2.7 Update..................................................9 2.8 Python 2 Deprecation Notice....................................... 10 3 Getting Started 11 3.1 An MD5 hash calculator using the Poco Libraries............................ 11 3.2 Installing Dependencies......................................... 14 3.3 Inspecting Dependencies......................................... 15 3.4 Searching Packages........................................... 18 3.5 Building with Other Configurations................................... 18 4 Using packages 21 4.1 Installing dependencies......................................... 21 4.2 Using profiles............................................... 26 4.3 Workflows................................................ 27 4.4 Debugging packages........................................... 29 5 Creating Packages 31 5.1 Getting Started.............................................. 31 5.2 Recipe and Sources in a Different Repo................................. 36 5.3 Recipe and Sources in the Same Repo.................................. 37 5.4 Packaging Existing Binaries....................................... 40 5.5 Understanding Packaging........................................ 42 5.6 Defining Package ABI Compatibility.................................. 44 5.7 Define the package information..................................... 57 5.8 Inspecting Packages........................................... 59 i 5.9 Packaging Approaches.......................................... 59 5.10 Package Creator Tools.......................................... 64 6 Uploading Packages 67 6.1 Remotes................................................. 67 6.2 Uploading Packages to Remotes..................................... 68 6.3 Using Bintray............................................... 69 6.4 Artifactory Community Edition for C/C++............................... 71 6.5 Running conan_server.......................................... 72 7 Developing packages 79 7.1 Package development flow........................................ 79 7.2 Packages in editable mode........................................ 83 7.3 Workspaces................................................ 87 8 Package apps and devtools 95 8.1 Running and deploying packages.................................... 95 8.2 Creating conan packages to install dev tools............................... 101 8.3 Build requirements............................................ 104 9 Versioning 109 9.1 Introduction to versioning........................................ 109 9.2 Version ranges.............................................. 113 9.3 Package Revisions............................................ 114 9.4 Lockfiles................................................. 115 10 Mastering Conan 123 10.1 Use conanfile.py for consumers..................................... 123 10.2 Conditional settings, options and requirements............................. 125 10.3 Build policies............................................... 127 10.4 Environment variables.......................................... 127 10.5 Virtual Environments........................................... 129 10.6 Logging.................................................. 130 10.7 Sharing the settings and other configuration............................... 133 10.8 Conan local cache: concurrency, Continuous Integration, isolation................... 133 11 Systems and cross building 135 11.1 Cross building.............................................. 135 11.2 Windows Subsystems.......................................... 146 12 Extending Conan 151 12.1 Customizing settings........................................... 151 12.2 Python requires.............................................. 154 12.3 Python requires (legacy)......................................... 158 12.4 Hooks................................................... 162 13 Integrations 167 13.1 Compilers................................................ 167 13.2 Build systems............................................... 167 13.3 IDEs................................................... 193 13.4 CI Platforms............................................... 208 13.5 Other Systems.............................................. 226 13.6 Version Control System......................................... 245 13.7 Custom integrations........................................... 246 13.8 Linting.................................................. 251 ii 13.9 Deployment............................................... 251 14 Configuration 257 14.1 Download cache............................................. 257 15 Howtos 259 15.1 How to package header-only libraries.................................. 259 15.2 How to launch conan install from cmake................................ 261 15.3 How to create and reuse packages based on Visual Studio....................... 262 15.4 Creating and reusing packages based on Makefiles........................... 265 15.5 How to manage the GCC >= 5 ABI................................... 267 15.6 Using Visual Studio 2017 - CMake integration............................. 268 15.7 Working with Intel compiler....................................... 271 15.8 How to manage C++ standard [EXPERIMENTAL]........................... 271 15.9 How to use Docker to create and cross-build C and C++ Conan packages............... 273 15.10 How to reuse Python code in recipes................................... 275 15.11 How to create and share a custom generator with generator packages................. 278 15.12 How to manage shared libraries..................................... 282 15.13 How to reuse cmake install for package() method............................ 287 15.14 How to collaborate with other users’ packages............................. 287 15.15 How to link with Apple Frameworks.................................. 288 15.16 How to package Apple Frameworks................................... 288 15.17 How to collect licenses of dependencies................................. 289 15.18 How to extract licenses from headers.................................. 289 15.19 How to dynamically define the name and version of a package..................... 290 15.20 How to capture package version from SCM: git............................. 290 15.21 How to capture package version from SCM: svn............................ 290 15.22 How to capture package version from text or build files......................... 291 15.23 How to use Conan as other language package manager......................... 291 15.24 How to manage SSL (TLS) certificates................................. 296 15.25 How to check the version of the Conan client inside a conanfile.................... 297 15.26 Use a generic CI with Conan and Artifactory.............................. 298 15.27 Compiler sanitizers............................................ 300 16 Reference 303 16.1 Commands................................................ 303 16.2 conanfile.txt............................................... 369 16.3 conanfile.py............................................... 371 16.4 Generators................................................ 409 16.5 Profiles.................................................. 442 16.6 Build helpers............................................... 446 16.7 Tools................................................... 469 16.8 Configuration files............................................ 496 16.9 Environment variables.......................................... 508 16.10 Hooks................................................... 517 16.11 CONAN_V2_MODE.......................................... 520 17 Videos and links 523 18 FAQ 525 18.1 General.................................................. 525 18.2 Using Conan............................................... 526 18.3 Troubleshooting............................................. 529 19 Glossary 533 iii 20 Changelog 537 20.1 1.25.2 (19-May-2020).......................................... 537 20.2 1.25.1 (13-May-2020).......................................... 537 20.3 1.25.0 (06-May-2020).......................................... 537 20.4 1.24.1 (21-Apr-2020)........................................... 538 20.5 1.24.0 (31-Mar-2020).......................................... 538 20.6 1.23.0 (10-Mar-2020).......................................... 539 20.7 1.22.3 (05-Mar-2020).......................................... 540 20.8 1.22.2 (13-Feb-2020)........................................... 540 20.9 1.22.1 (11-Feb-2020)........................................... 540 20.10 1.22.0 (05-Feb-2020)........................................... 541 20.11 1.21.3 (03-Mar-2020).........................................
Load more

Recommended publications
  • Continuous Integration
    Continuous Integration Mark C. Miller Lawrence Livermore National Laboratory Software Productivity Track, ATPESC 2020 See slide 2 for license details exascaleproject.org License, Citation and Acknowledgements License and Citation • This work is licensed under a Creative Commons Attribution 4.0 International License (CC BY 4.0). • The requested citation the overall tutorial is: David E. Bernholdt, Anshu Dubey, Mark C. Miller, Katherine M. Riley, and James M. Willenbring, Software Productivity Track, in Argonne Training Program for Extreme Scale Computing (ATPESC), August 2020, online. DOI: 10.6084/m9.figshare.12719834 • Individual modules may be cited as Speaker, Module Title, in Software Productivity Track… Acknowledgements • Additional contributors include: Patricia Grubel, Rinku Gupta, Mike Heroux, Alicia Klinvex, Jared O’Neal, David Rogers, Deborah Stevens • This work was supported by the U.S. Department of Energy Office of Science, Office of Advanced Scientific Computing Research (ASCR), and by the Exascale Computing Project (17-SC-20-SC), a collaborative effort of the U.S. Department of Energy Office of Science and the National Nuclear Security Administration. • This work was performed in part at the Argonne National Laboratory, which is managed by UChicago Argonne, LLC for the U.S. Department of Energy under Contract No. DE-AC02-06CH11357. • This work was performed in part at the Oak Ridge National Laboratory, which is managed by UT-Battelle, LLC for the U.S. Department of Energy under Contract No. DE-AC05-00OR22725. • This work was performed in part at the Lawrence Livermore National Laboratory, which is managed by Lawrence Livermore National Security, LLC for the U.S. Department of Energy under Contract No.
    [Show full text]
  • Usage, Costs, and Benefits of Continuous Integration in Open
    Usage, Costs, and Benefits of Continuous Integration in Open-Source Projects Michael Hilton Timothy Tunnell Kai Huang Oregon State University University of Illinois at University of Illinois at [email protected] Urbana-Champaign Urbana-Champaign [email protected] [email protected] Darko Marinov Danny Dig University of Illinois at Oregon State University Urbana-Champaign [email protected] [email protected] ABSTRACT CI using several quality metrics. However, the study does Continuous integration (CI) systems automate the compi- not present any detailed information about the use of CI. lation, building, and testing of software. Despite CI rising In fact, despite some folkloric evidence about the use of CI, as a big success story in automated software engineering, it there is no systematic study about CI systems. has received almost no attention from the research commu- Not only do we lack basic knowledge about the extent nity. For example, how widely is CI used in practice, and to which open-source projects are adopting CI, but also what are some costs and benefits associated with CI? With- we have no answers to many other important questions re- out answering such questions, developers, tool builders, and lated to CI. What are the costs of CI? Does CI deliver researchers make decisions based on folklore instead of data. on the promised benefits, such as releasing more often, or In this paper, we use three complementary methods to helping make changes (e.g., to merge pull requests) faster? study in-depth the usage of CI in open-source projects. To Are developers maximizing the usage of CI? Despite the understand what CI systems developers use, we analyzed widespread popularity of CI, we have very little quantita- 34,544 open-source projects from GitHub.
    [Show full text]
  • Open Source Best Practices: from Continuous Integration to Static Linters
    THE MOLECULAR SCIENCES SOFTWARE INSTITUTE - LOGO CONCEPTS ROUND 2 Open Source Best Practices: From Continuous Integration to Static Linters Daniel G. A. Smith and Ben Pritchard The Molecular Sciences Software Institute !1 @dga_smith / @molssi_nsf 1. 3 The Molecular Sciences Software Institute (MolSSI) •Designed to serve and enhance the software development efforts of the broad field of computational molecular science (CMS). •Funded at the institute level under the Software Infrastructure for Sustained Innovation (SI2) initiative by the National Science Foundation. •Launched August 1st, 2016 •Collaborative effort by: •Virginia Tech •U.C. Berkeley •U. Southern •Rice U. •Stanford U. California •Stony Brook U. •Rutgers U. •Iowa State U. !2 The Molecular Sciences Software Institute (MolSSI) •Software Infrastructure •Build open-source frameworks and packages for the entire CMS community •Education and training •Online materials and training guides •Host a number of targeted workshops, summer schools, and other training programs •Community Engagement and Leadership •Interoperability standards and best practices !3 •Data and API standardization targets Talk Motivation •Many terms thrown around: •Best Practice •Manage Code •DevOps •Build and Package •Open Source •“Just get the physics •Software Sustainability working” •“Incorrect Software” “Best” is subjective and depends on your own community. Lets discuss practical applications and how to make our lives easier! !4 Open Source Open Source software is software that can be freely accessed, used,
    [Show full text]
  • PIP-II Technical Workshop Software Development Strategy Discussion
    PIP-II Technical Workshop Software Development Strategy Discussion A Partnership of: Tanya Levshina US/DOE SCD/CPI India/DAE Italy/INFN 1-4 December 2020 UK/UKRI-STFC France/CEA, CNRS/IN2P3 Poland/WUST Outline • Key to successful collaboration in global inter‐organizational software development projects • Selection of a shared repository platform • Project organization 2 1-4 December 2020 PIP-II Technical Workshop Key Ingredients for a Successful Project • Clear understanding of – requirements and scope – roles and roadmap • Communication and ongoing reviews • Documentation • Well structured code • Shared repository 3 1-4 December 2020 PIP-II Technical Workshop Shared code repository • Effectively share code in a managed way to speed up development • Avoid code duplication • Encourage best practices in code development • Improve code quality and provide means for collaboration 4 1-4 December 2020 PIP-II Technical Workshop Open-Source Version Control Software (VCS) Software History Current Repository Atomic Signed Merge Interactive Users Status model Commit revision Tracking Commit First publicly NetBSD, OpenBSD CVS Maintained Client-server No No No No released July 3, but new 1986; based on features not RCS added. Last release from 2008. Subversion Started in Active Client-server Yes No Yes Partial ASF, gcc, SourceForge, FreeBSD, (SVN) 2000 by CVS GoogleCode, PuTTY, Apache OpenOffice, developers TWiki with goal of replacing CVS Mercurial Started by Active Distributed Yes Yes Yes Yes Was used by Facebook and Mozilla at Matt Mackall some point in 2005 GNU Bazaar Canonical Ltd Active Distributed Yes Yes Yes Yes MariaDB, Squid, PyChart, Linux Foundation GIT Started by Active Distributed Yes Yes Yes Yes Linux kernel, Android, Bugzilla, LG, jQuery, Linus DragonFly BSD, GNOME, GNU Emacs, KDE, Torvalds in MySQL, Ericsson, Microsoft, Huawei, April 2005.
    [Show full text]
  • Hunter Documentation Release 0.23
    Hunter Documentation Release 0.23 Ruslan Baratov Aug 20, 2021 Contents 1 Brief overview 3 2 Quick start 15 3 User guides 19 4 Packages 51 5 Creating new package 245 6 FAQ 273 7 Contributing 295 8 Contacts 299 9 Reference 301 Index 345 i ii Hunter Documentation, Release 0.23 Welcome to the Hunter package manager documentation! Hunter is a CMake driven cross-platform package manager for C/C++1 projects. With the help of Hunter you can organize builds for Linux, Windows, macOS, iOS, Android, Raspberry Pi and other platforms. Third-party external projects are highly customizable, effectively allowing you to have myriad variants of directories with them based on combinations of version to build, static/shared, CMake -D options, Release/Debug, etc. Separate root directories will be created for each variant, so they all can be used simultaneously on one machine without conflicts (just like virtualenv but automatically). Going further: each such root directory can be shared between several local projects if configuration of externals matches. So when you are starting another project from scratch and use the same external packages, there will be no additional copy or build triggered; the only overhead is checking the existence of a DONE stamp file for each package. In case your local environment is similar enough to the continuous integration environment of Travis/AppVeyor service, then build will not be triggered at all - cached binaries will be downloaded from GitHub server instead. Mainly Hunter is designed to manage packages with CMake build system under the hood and existing CMake packages can be quite easily integrated into system, but non-CMake packages are also supported too using custom templates (build schemes) with ExternalProject_Add command(s).
    [Show full text]
  • Collaboration Tools in Software Engineering Stepan Bolotnikov Lecture 6: Advanced Git Usage Today
    Collaboration Tools in Software Engineering Stepan Bolotnikov Lecture 6: Advanced Git usage Today By the end of this lecture, you will know: ● What is Continuous Integration and Continuous Deployment ● Why they are useful ● What are Git hooks ● What kind of hooks Git provides ● How to use Git hooks After writing code ● Source code must be tested for errors continuously ● Developers should write automatic tests that can be run ● Instead of triggering tests automatically, would be better if system did it for us before the new code is committed ● Deploy application to test server after a newer code is committed ● Rebuild and deploy each time someone pushes a change ● Make the latest version available to customers and testers at all times ● Must be done automatically, otherwise waste of resources CI and CD ● Continuous Integration ○ Testing all changes to codebase automatically and as early as possible ○ Every time a change is commited, a suite of test scripts is automatically run ○ Developers informed about errors ● Continuous Deployment ○ Automatically making the latest stable (tested) version of your application available at all times ○ When CI tests pass, a new version is built and deployed How to CI/CD ● Tools provided by repository hosting ○ GitLab CI ○ BitBucket Pipelines ● Integrations ○ GitHub doesn’t have own CI/CD tools ○ Integrates other tools ○ Travis CI, Jenkins, AppVeyor and others ○ https://github.com/marketplace/category/continuous-integration ● Separate software ● Built-in Git tools - hooks Git hooks ● Allow to run custom scripts when an event happens ● Available for client-side (local repositories) and server-side (remote repositories) ● Scripts can be written in any language ● Every time a repository is created, example scripts are added Types of Git hooks 1.
    [Show full text]
  • Usage, Costs, and Benefits of Continuous Integration in Open
    Usage, Costs, and Benefits of Continuous Integration in Open-Source Projects Michael Hilton Timothy Tunnell Kai Huang Oregon State University, USA University of Illinois, USA University of Illinois, USA [email protected] [email protected] [email protected] Darko Marinov Danny Dig University of Illinois, USA Oregon State University, USA [email protected] [email protected] ABSTRACT deployment of software. For example, such automation has Continuous integration (CI) systems automate the compila- been reported [22] to help Flickr deploy to production more tion, building, and testing of software. Despite CI rising as than 10 times per day. Others [40] claim that by adopting a big success story in automated software engineering, it has CI and a more agile planning process, a product group at received almost no attention from the research community. HP reduced development costs by 78%. For example, how widely is CI used in practice, and what are These success stories have led to CI growing in interest some costs and benefits associated with CI? Without answer- and popularity. Travis CI [17], a popular CI service, reports ing such questions, developers, tool builders, and researchers that over 300,000 projects are using Travis. The State of make decisions based on folklore instead of data. Agile industry survey [48], with 3,880 participants, found In this paper, we use three complementary methods to 50% of respondents use CI. The State of DevOps report [49] study the usage of CI in open-source projects. To understand finds CI to be one of the indicators of "high performing IT which CI systems developers use, we analyzed 34,544 open- organizations".
    [Show full text]
  • Introduction to Project Management in COIN-OR
    Project Management The COIN-OR Way Ted Ralphs COIN fORgery: Developing Open Source Tools for OR Institute for Mathematics and Its Applications, Minneapolis, MN T.K. Ralphs (Lehigh University) COIN-OR October 15, 2018 Preamble I’ll touch on a ton of stuff here, some of which may already be familiar to some. It wasn’t clear exactly what order to go in or how much background knowledge to assume. Please do stop me as often as you like and we can drill down on topics of interest. I may also say something that you disagree with. My thoughts on topics like the proper workflow for COIN in the Github environment is still evolving. Let’s have some good discussion! T.K. Ralphs (Lehigh University) COIN-OR October 15, 2018 Outline 1 Intellectual Property 2 Toolbox 3 Version Control Versioning svn and git Utilities 4 Dependencies 5 Repository Contents T.K. Ralphs (Lehigh University) COIN-OR October 15, 2018 Intellectual Property: Ownership It is important to know who owns your code, since it may not be you. In the U.S., your employer probably owns your code, even if you’re an academic, but this may not be true in other countries. Only the legal owner may license the code, which is a necessary step for making your project open source and useful to others. It is important o carefully track contributions to your project by others so that the entirety of your project remains legally licensed. COIN-OR requires all contrbutors to sign legal paperwork certifying that they understand all this.
    [Show full text]
  • Continuous Integration
    Continuous Integration James M. Willenbring Sandia National Laboratories David E. Bernholdt Oak Ridge National Laboratory Mark C. Miller Lawrence Livermore National Laboratory Developing a Testing and Continuous Integration Strategy for your Team tutorial @ ECP Annual Meeting, April 2021 See slide 2 for license details exascaleproject.org License, Citation and Acknowledgements License and Citation • This work is licensed under a Creative Commons Attribution 4.0 International License (CC BY 4.0). • The requested citation the overall tutorial is: David E. Bernholdt, Patricia A. Grubel, and James M. Willenbring, Developing a Testing and Continuous Integration Strategy for your Team tutorial, in Exascale Computing Project Annual Meeting, online, 2021. DOI: 10.6084/m9.figshare.14376956 • Individual modules may be cited as Speaker, Module Title, in Better Scientific Software tutorial… Acknowledgements • Additional contributors include: David E. Bernholdt, Anshu Dubey, Rinku K. Gupta, Mike Heroux, Alicia Klinvex, Mark Miller, Jared O’Neal, Katherine Riley, David Rogers, Deborah Stevens, James Willenbring • This work was supported by the U.S. Department of Energy Office of Science, Office of Advanced Scientific Computing Research (ASCR), and by the Exascale Computing Project (17-SC-20-SC), a collaborative effort of the U.S. Department of Energy Office of Science and the National Nuclear Security Administration. • This work was performed in part at the Argonne National Laboratory, which is managed by UChicago Argonne, LLC for the U.S. Department of Energy under Contract No. DE-AC02-06CH11357. • This work was performed in part at the Oak Ridge National Laboratory, which is managed by UT-Battelle, LLC for the U.S. Department of Energy under Contract No.
    [Show full text]
  • Creating and Sharing Reproducible Research Code the Workflowr Way [Version 1; Peer Review: 3 Approved]
    F1000Research 2019, 8:1749 Last updated: 28 JUL 2021 SOFTWARE TOOL ARTICLE Creating and sharing reproducible research code the workflowr way [version 1; peer review: 3 approved] John D. Blischak 1, Peter Carbonetto 1,2, Matthew Stephens1,3 1Department of Human Genetics, University of Chicago, Chicago, IL, 60637, USA 2Research Computing Center, University of Chicago, Chicago, IL, 60637, USA 3Department of Statistics, University of Chicago, Chicago, IL, 60637, USA v1 First published: 14 Oct 2019, 8:1749 Open Peer Review https://doi.org/10.12688/f1000research.20843.1 Latest published: 14 Oct 2019, 8:1749 https://doi.org/10.12688/f1000research.20843.1 Reviewer Status Invited Reviewers Abstract Making scientific analyses reproducible, well documented, and easily 1 2 3 shareable is crucial to maximizing their impact and ensuring that others can build on them. However, accomplishing these goals is not version 1 easy, requiring careful attention to organization, workflow, and 14 Oct 2019 report report report familiarity with tools that are not a regular part of every scientist's toolbox. We have developed an R package, workflowr, to help all 1. Peter F. Hickey , Walter and Eliza Hall scientists, regardless of background, overcome these challenges. Workflowr aims to instill a particular "workflow" — a sequence of Institute of Medical Research, Parkville, steps to be repeated and integrated into research practice — that Australia helps make projects more reproducible and accessible.This workflow integrates four key elements: (1) version control (via Git); (2) literate 2. Przemysław Biecek , Warsaw University programming (via R Markdown); (3) automatic checks and safeguards of Technology, Warsaw, Poland that improve code reproducibility; and (4) sharing code and results via a browsable website.
    [Show full text]
  • Smalltalkci a Continuous Integration Framework for Smalltalk Projects
    smalltalkCI A Continuous Integration Framework for Smalltalk Projects Fabio Niephaus Dale Henrichs Marcel Taeumel Hasso Plattner Institute GemTalk Systems Hasso Plattner Institute University of Potsdam, Germany [email protected] University of Potsdam, Germany [email protected] [email protected] Tobias Pape Tim Felgentreff Robert Hirschfeld Hasso Plattner Institute Hasso Plattner Institute Hasso Plattner Institute University of Potsdam, Germany University of Potsdam, Germany University of Potsdam, Germany [email protected] tim.felgentreff@hpi.de [email protected] Abstract 1. Introduction Continuous integration (CI) is a programming practice that Working collaboratively with a shared code base is a cogni- reduces the risk of project failure by integrating code changes tive challenge. Adapting best practices such as test-driven multiple times a day. This has always been important to the development increases code quality [9] and therefore its read- Smalltalk community, so custom integration infrastructures ability and maintainability. In order to make a project usable are operated that allow CI testing for Smalltalk projects for others, it is often necessary to use dependency manage- shared in Monticello repositories or traditional changesets. ment tools. However, this still does not guarantee that a given In the last few years, the open hosting platform GitHub program works for another developer or even for an end-user. has become more and more popular for Smalltalk projects. Continuous integration (CI) [5] is an extreme programming Unfortunately, there was no convenient way to enable CI practice that allows developers to change and refactor code testing for those projects. while reducing the risk of project failure [2, 8].
    [Show full text]
  • The Release Pipeline Model Applied to Managing Windows Server and the Microsoft Cloud
    The Release Pipeline Model Applied to managing Windows Server and the Microsoft Cloud Publication Date: April 2016 Authors: Michael Greene (Microsoft), Steven Murawski (Chef Software, Inc) Contributors: Editor: Glenn Minch (Aquent LLC); Technica l Reviews: Levi Geinert, Jason Rutherford (Model Technology Solutions); Matthew Wetmore (Microsoft) ; Jim Britt (Microsoft) Summary: There are benefits to be gained when patterns and practices from developer techniques are applied to operations. Notably, a fully automated solution where infrastructure is managed as code and all changes are automatically validated before reaching production. This is a process shift that is recognized among industry innovators. For organizations already leveraging these proces ses, it should be clear how to leverage Microsoft platforms. For organizations that are new to the topic, it should be clear how to bring this process to your environment and what it means to your organizational culture. This document explains the componen ts of a Release Pipeline for configuration as code, the value to operations, and solutions that are used when designing a new Release Pipeline architecture. © 2016 Microsoft Corporation. All rights reserved. This document is provided "as-is." Information and views expressed in this document, including URL and other Internet Web site references, may change without notice. You bear the risk of using it. Some examples are for illustration only and are fictitious. No real association is intended or inferred. This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes. You may modify this document for your internal, reference purposes.
    [Show full text]