DOCSLIB.ORG

Learning Devops.Pdf

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Learning Devops.Pdf Learning DevOps The complete guide to accelerate collaboration with Jenkins, Kubernetes, Terraform and Azure DevOps Mikael Krief BIRMINGHAM - MUMBAI Learning DevOps Copyright © 2019 Packt Publishing All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews. Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book. Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information. Commissioning Editor: Vijin Boricha Acquisition Editor: Meeta Rajani Content Development Editor: Drashti Panchal Senior Editor: Arun Nadar Technical Editor: Prachi Sawant Copy Editor: Safis Editing Project Coordinator: Vaidehi Sawant Proofreader: Safis Editing Indexer: Tejal Daruwale Soni Production Designer: Nilesh Mohite First published: October 2019 Production reference: 1251019 Published by Packt Publishing Ltd. Livery Place 35 Livery Street Birmingham B3 2PB, UK. ISBN 978-1-83864-273-0 www.packt.com I would like to dedicate this book to my wife and children, who are my source of happiness. Foreword Having discussed DevOps with Mikael Krief on several occasions, it is clear that he understands the importance of empowering both Dev and Ops in order to deliver value. DevOps is the union of people, processes, and products to enable the continuous delivery of value to our end users. Value is the most important word of that definition. DevOps is not about software, automation, shipping a feature, or getting to the bottom of your product backlog. It is about delivering value. To deliver value, you must measure your application while it is running in production and use the telemetry to guide what you deliver next. To deliver value, your team must fully embrace the culture of DevOps. The hardest part of DevOps is the people part: building the culture that is required to succeed. Learning DevOps does a great job of focusing on the culture behind DevOps. To succeed, you must change the way your team thinks about their roles. Everyone must have a common goal that encourages collaboration. Delivering value to the end user is the responsibility of everyone involved in the application. Our community tends to spend more time on the Dev side of DevOps. Learning DevOps, however, has invested considerable time on Infrastructure as Code. As more workloads move to the cloud, IaC becomes more valuable. The ability to provision and configure your infrastructure as part of your pipeline allows engineers to innovate. IaC can save companies money by shutting down environments when they are no longer in use or simply provisioning them on demand. Once your entire infrastructure is stored in version control and acted upon via your pipeline, recovering from a disaster is simply a deployment. The time to debate whether you should or should not implement DevOps is over. You either implement DevOps or you lose. Donovan Brown Principal Cloud Advocate Manager at Microsoft Packt.com Subscribe to our online digital library for full access to over 7,000 books and videos, as well as industry leading tools to help you plan your personal development and advance your career. For more information, please visit our website. Why subscribe? Spend less time learning and more time coding with practical eBooks and Videos from over 4,000 industry professionals Improve your learning with Skill Plans built especially for you Get a free eBook or video every month Fully searchable for easy access to vital information Copy and paste, print, and bookmark content Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at www.packt.com and as a print book customer, you are entitled to a discount on the eBook copy. Get in touch with us at [email protected] for more details. At www.packt.com, you can also read a collection of free technical articles, sign up for a range of free newsletters, and receive exclusive discounts and offers on Packt books and eBooks. Contributors About the author Mikael Krief lives in France and works as a DevOps engineer, and for 4 years he has worked as a DevOps consultant and DevOps technical officer at an expert consulting company in Microsoft technologies. He is passionate about DevOps culture and practices, ALM, and Agile methodologies. He loves to share his passion through various communities, such as the ALM | DevOps Rangers community, which he has been a member of since 2015. He also contributes to many open source projects, writes blogs and books, speaks at conferences, and publishes public tools such as extensions for Azure DevOps. For all his contributions and passion in this area, he has received the Microsoft© Most Valuable Professional (MVP) award for the last 4 years. I would like to extend my thanks to my family for accepting that I needed to work long hours on this book during family time. I would like to thank Meeta Rajani for giving me the opportunity to write this book, which was a very enriching experience. Special thanks to Drashti Panchal, Prachi Sawant, Arun Nadar for their valuable input and time reviewing this book and to the entire Packt team for their support during the course of writing this book. About the reviewers Abhinav Krishna Kaiser manages in a leading consulting firm. He is a published author and has penned three books on DevOps, ITIL, and IT communication. Abhinav has transformed multiple programs into the DevOps ways of working and is one of the leading DevOps architects on the circuit today. He has assumed the role of an Agile Coach to set the course for Agile principles and processes in order to set the stage in development. Apart from DevOps and Agile, Abhinav is an ITIL expert and is a popular name in the field of IT service management. Abhinav's latest publication, on recasting ITIL with the DevOps processes, came out in 2018. Reinventing ITIL in the Age of DevOps transforms the ITIL framework to work in a DevOps project. His earlier publication, Become ITIL Foundation Certified in 7 Days, is one of the top guides for IT professionals looking to become ITIL Foundation certified and to those getting into the field of service management. Abhinav started consulting with clients 15 years ago on IT service management, where he created value by developing robust service management solutions. Moving with the times, he eventually went into DevOps and Agile consulting. He is one of the foremost authorities in the area of configuration management and his solutions have stood the test of time, rigor, and technological advancements. Abhinav blogs and writes guides and articles on DevOps, Agile, and ITIL on popular sites. While the life of a consultant is to go where the client is, currently he is based in London, UK. He is from Bangalore, India, and is happily married with a daughter and a son. Ebru Cucen works as a technical principal consultant at Contino, and is also a public speaker and trainer on Serverless. She has a BSc in mathematics and started her journey as a .NET developer/trainer in 2004. She has over 10 years of experience in digital transformation of financial enterprise companies. She's spent the last 5 years working with the cloud, covering the full life cycle of feature development/deployment and CI/CD pipelines. Being a lifetime student, she loves learning, exploring, and experimenting with technology to understand and use it to make our lives better. She enjoys living in London with her 7-year-old son and her husband, Tolga Cucen, to whom she is thankful for supporting her during the nights/weekends she has worked on this book. Packt is searching for authors like you If you're interested in becoming an author for Packt, please visit authors.packtpub.com and apply today. We have worked with thousands of developers and tech professionals, just like you, to help them share their insight with the global tech community. You can make a general application, apply for a specific hot topic that we are recruiting an author for, or submit your own idea. Table of Contents Preface 1 Section 1: DevOps and Infrastructure as Code Chapter 1: DevOps Culture and Practices 8 Getting started with DevOps 9 Implementing CI/CD and continuous deployment 12 Continuous integration (CI) 12 Implementing CI 13 Continuous delivery (CD) 15 Continuous deployment 17 Understanding IaC practices 19 The benefits of IaC 19 IaC languages and tools 20 Scripting types 20 Declarative types 20 The IaC topology 22 The deployment and provisioning of the infrastructure 22 Server configuration 22 Immutable infrastructure with containers 24 Configuration and deployment in Kubernetes 24 IaC best practices 25 Summary 27 Questions 28 Further reading 28 Chapter 2: Provisioning Cloud Infrastructure with Terraform 29 Technical requirements 29 Installing Terraform 30 Manual installation 30 Installation by script 31 Installing Terraform by script on Linux 31 Installing
Load more

Recommended publications
  • Distributed Configuration Management: Mercurial CSCI 5828 Spring 2012 Mark Grebe Configuration Management
    Distributed Configuration Management: Mercurial CSCI 5828 Spring 2012 Mark Grebe Configuration Management Configuration Management (CM) systems are used to store code and other artifacts in Software Engineering projects. Since the early 70’s, there has been a progression of CM systems used for Software CM, starting with SCCS, and continuing through RCS, CVS, and Subversion. All of these systems used a single, centralized repository structure. Distributed Configuration Management As opposed to traditional CM systems, Distributed Configuration Management Systems are ones where there does not have to be a central repository. Each developer has a copy of the entire repository and history. A central repository may be optionally used, but it is equal to all of the other developer repositories. Advantages of Distributed Configuration Management Distributed tools are faster than centralized ones since metadata is stored locally. Can use tool to manage changes locally while not connected to the network where server resides. Scales more easily, since all of the load is not on a central server. Allows private work that is controlled, but not released to the larger community. Distributed systems are normally designed to make merges easy, since they are done more often. Mercurial Introduction Mercurial is a cross-platform, distributed configuration management application. In runs on most modern OS platforms, including Windows, Linux, Solaris, FreeBSD, and Mac OSX. Mercurial is written 95% in Python, with the remainder written in C for speed. Mercurial is available as a command line tool on all of the platforms, and with GUI support programs on many of the platforms. Mercurial is customizable with extensions, hooks, and output templates.
    [Show full text]
  • Distributed Revision Control with Mercurial
    Distributed revision control with Mercurial Bryan O’Sullivan Copyright c 2006, 2007 Bryan O’Sullivan. This material may be distributed only subject to the terms and conditions set forth in version 1.0 of the Open Publication License. Please refer to Appendix D for the license text. This book was prepared from rev 028543f67bea, dated 2008-08-20 15:27 -0700, using rev a58a611c320f of Mercurial. Contents Contents i Preface 2 0.1 This book is a work in progress ...................................... 2 0.2 About the examples in this book ..................................... 2 0.3 Colophon—this book is Free ....................................... 2 1 Introduction 3 1.1 About revision control .......................................... 3 1.1.1 Why use revision control? .................................... 3 1.1.2 The many names of revision control ............................... 4 1.2 A short history of revision control .................................... 4 1.3 Trends in revision control ......................................... 5 1.4 A few of the advantages of distributed revision control ......................... 5 1.4.1 Advantages for open source projects ............................... 6 1.4.2 Advantages for commercial projects ............................... 6 1.5 Why choose Mercurial? .......................................... 7 1.6 Mercurial compared with other tools ................................... 7 1.6.1 Subversion ............................................ 7 1.6.2 Git ................................................ 8 1.6.3
    [Show full text]
  • DVCS Or a New Way to Use Version Control Systems for Freebsd
    Brief history of VCS FreeBSD context & gures Is Arch/baz suited for FreeBSD? Mercurial to the rescue New processes & policies needed Conclusions DVCS or a new way to use Version Control Systems for FreeBSD Ollivier ROBERT <[email protected]> BSDCan 2006 Ottawa, Canada May, 12-13th, 2006 Ollivier ROBERT <[email protected]> DVCS or a new way to use Version Control Systems for FreeBSD Brief history of VCS FreeBSD context & gures Is Arch/baz suited for FreeBSD? Mercurial to the rescue New processes & policies needed Conclusions Agenda 1 Brief history of VCS 2 FreeBSD context & gures 3 Is Arch/baz suited for FreeBSD? 4 Mercurial to the rescue 5 New processes & policies needed 6 Conclusions Ollivier ROBERT <[email protected]> DVCS or a new way to use Version Control Systems for FreeBSD Brief history of VCS FreeBSD context & gures Is Arch/baz suited for FreeBSD? Mercurial to the rescue New processes & policies needed Conclusions The ancestors: SCCS, RCS File-oriented Use a subdirectory to store deltas and metadata Use lock-based architecture Support shared developments through NFS (fragile) SCCS is proprietary (System V), RCS is Open Source a SCCS clone exists: CSSC You can have a central repository with symlinks (RCS) Ollivier ROBERT <[email protected]> DVCS or a new way to use Version Control Systems for FreeBSD Brief history of VCS FreeBSD context & gures Is Arch/baz suited for FreeBSD? Mercurial to the rescue New processes & policies needed Conclusions CVS, the de facto VCS for the free world Initially written as shell wrappers over RCS then rewritten in C Centralised server Easy UI Use sandboxes to avoid locking Simple 3-way merges Can be replicated through CVSup or even rsync Extensive documentation (papers, websites, books) Free software and used everywhere (SourceForge for example) Ollivier ROBERT <[email protected]> DVCS or a new way to use Version Control Systems for FreeBSD Brief history of VCS FreeBSD context & gures Is Arch/baz suited for FreeBSD? Mercurial to the rescue New processes & policies needed Conclusions CVS annoyances and aws BUT..
    [Show full text]
  • Version Control Key Points ======
    Version Control Key Points ========================== Mike Jackson, The Software Sustainability Institute. This work is licensed under the Creative Commons Attribution License. Copyright (c) Software Carpentry and The University of Edinburgh 2012. See http://software-carpentry.org/license.html for more information. Derived from Chris Cannam's original at, https://code.soundsoftware.ac.uk/projects/easyhg/wiki/SC2012BootcampPl an. .. Written in reStructuredText, http://docutils.sourceforge.net/rst.html. Prerequisites ------------- Mercurial, BitBucket. Introduction ------------ Cover VersionControl.ppt, slides 1-2. Use Mercurial command-line. EasyMercurial GUI as a visually appealing alternative - once the concepts are understood. Create a repository directory and add a file -------------------------------------------- hg and Mercury. Set an editor for providing commit messages e.g. nano. :: export EDITOR=nano Or xemacs :: export EDITOR=xemacs Or vi. :: export EDITOR=vi Create repository. :: hg init hg status file.txt "?" means repository does not know about it. :: hg add file.txt hg status file.txt "A" means repository has scheduled it for addition but not yet added it. :: hg commit file.txt abort: no username supplied message /home/user/.hgrc file contains common settings. :: [ui] username = Boot Camp <[email protected]> :: hg commit file.txt Commit message records "why" changes were made. "made a change" messages are redundant. "Commit 1, 2..." messages are redundant. Messages must have meaning to others who may read them (or the original author 6 months from now). :: hg status file.txt No information means repository knows about it and it's up-to-date. .hgignore can record files to ignore e.g. ~ files, .o files, .class files etc. :: syntax: glob *~ Add to repository.
    [Show full text]
  • Hg Mercurial Cheat Sheet Serge Y
    Hg Mercurial Cheat Sheet Serge Y. Stroobandt Copyright 2013–2020, licensed under Creative Commons BY-NC-SA #This page is work in progress! Much of the explanatory text still needs to be written. Nonetheless, the basic outline of this page may already be useful and this is why I am sharing it. In the mean time, please, bare with me and check back for updates. Distributed revision control Why I went with Mercurial • Python, Mozilla, Java, Vim • Mercurial has been better supported under Windows. • Mercurial also offers named branches Emil Sit: • August 2008: Mercurial offers a comfortable command-line experience, learning Git can be a bit daunting • December 2011: Git has three “philosophical” distinctions in its favour, as well as more attention to detail Lowest common denominator It is more important that people start using dis- tributed revision control instead of nothing at all. The Pro Git book is available online. Collaboration styles • Mercurial working practices • Collaborating with other people Use SSH shorthand 1 Installation $ sudo apt-get update $ sudo apt-get install mercurial mercurial-git meld Configuration Local system-wide configuration $ nano .bashrc export NAME="John Doe" export EMAIL="[email protected]" $ source .bashrc ~/.hgrc on a client user@client $ nano ~/.hgrc [ui] username = user@client editor = nano merge = meld ssh = ssh -C [extensions] convert = graphlog = mq = progress = strip = 2 ~/.hgrc on the server user@server $ nano ~/.hgrc [ui] username = user@server editor = nano merge = meld ssh = ssh -C [extensions] convert = graphlog = mq = progress = strip = [hooks] changegroup = hg update >&2 Initiating One starts with initiate a new repository.
    [Show full text]
  • Everything You Need to Know About Openjdk's Move to Git and Github
    Menu Topics Archives Downloads Subscribe Everything you need to know JAVA 17 about OpenJDK’s move to Git and GitHub Everything you need to know Blame or thank BitKeeper about OpenJDK’s move to Git Why not Mercurial? and GitHub Why Git? Why GitHub? Why the move, and why now? The move from Mercurial to Git Getting the source code and provided an opportunity to consolidate building the OpenJDK the source code repositories. Conclusion by Ian Darwin Dig deeper May 14, 2021 Download a PDF of this article Have you ever built your own Java Development Kit from source? Most end users of the JDK will not need to build their own JDK from the Oracle source code. I’ve needed to do that only a few times when I was running on the OpenBSD UNIX-like system, which is not one of the three supported platforms. Sure, you might want to build your own JDK to try out a new feature that you think should be added to Java. You might choose to build from source to be sure you are running a more trustworthy binary. Having the complete source code readily available, and now in a more commonly used download format, means it is easier than ever to build your own JDK. Yes, it’s a better-documented, easily configured process than in the past. But it’s still a bit confusing. The source code for the OpenJDK recently moved from the Mercurial version control system (VCS) to the Git VCS and the GitHub repository system, and that’s probably a good thing.
    [Show full text]
  • State of CI CD Survey, 2020
    STATE OF CI/CD SURVEY 2020 TABLE OF CONTENTS ActiveState CI/CD Survey 3 ActiveState and CI/CD – What’s the connection? 3 Part 1 - Demographics 4 Which title best describes your role? 5 What best describes your responsibilities with respect to CI/CD? 6 What is your organization’s principal industry? 7 How large is your organization? 8 How long has CI/CD been a standard practice for your team(s)? 9 What best describes your team's CI/CD practice? 10 Which CI/CD best practices have you implemented? 11 Part 2 - Technology 12 Which CI/CD tools do your teams currently use? 13 Which CI/CD tools do your teams want to adopt? 14 Which tool/vendor requirements are essential requirements? 15 What is preventing you from adopting new CI/CD tools? 16 How long would it take to adopt new CI/CD tools in your organization? 17 Which major deployment platforms does your organization use? 18 Which programming languages do you support in your CI/CD workflows? 19 Which artifact repositories are used at your organization? Choose one or more. 20 How do you employ artifact repositories in a CI/CD context? 21 Which tools do you use to manage dependencies and create runtime environments in your CI/CD workflow? 22 Part 3 - Key Findings 23 Overall, how satisfied are you with your CI/CD implementation? 24 Which major drawbacks of CI/CD has your organization experienced? 25 What are your top 3 challenges with managing language dependencies and runtimes? 26 How do you currently manage language runtimes for your CI/CD workflow? 27 Which major benefits of CI/CD have you realized? 28 Which benefits of CI/CD did you expect but have not realized? 29 Conclusions 30 About ActiveState 31 ACTIVESTATE CI/CD SURVEY ACTIVESTATE CI/CD SURVEY Continuous Integration and Continuous Delivery or Deployment (CI/CD) is an agile software development best practice designed to enable more frequent and reliable code updates.
    [Show full text]
  • An Introduction to Mercurial Version Control Software
    An Introduction to Mercurial Version Control Software CS595, IIT [Doc Updated by H. Zhang] Oct, 2010 Satish Balay [email protected] Outline ● Why use version control? ● Simple example of revisioning ● Mercurial introduction - Local usage - Remote usage - Normal user workflow - Organizing repositories [clones] ● Further Information ● [Demo] What do we use Version Control for? ● Keep track of changes to files ● Enable multiple users editing files simultaneously ● Go back and check old changes: * what was the change * when was the change made * who made the change * why was the change made ● Manage branches [release versions vs development] Simple Example of Revisioning main.c File Changes File Version 0 1 2 3 Delta Simple Example Cont. main.c 0 1 2 3 makefilemain.c 0 1 Repository -1 0 1 2 3 Version Changeset Concurrent Changes to a File by Multiple Users & Subsequent Merge of Changes Line1 Line1 Line1 Line1 Line2 UserA Line2 UserA Line3 Line2 Line3 Line2 Line4 Line3 UserB Line3 Line4 Line4 UserB Line4 Initial file UserA edit UserB edit Merge edits by both users Merge tools: r-2 ● kdiff3 Branch Merge ● meld r-4 Merge types: ● 2-way r-1 ● 3-way Revision Graph r-3 Some Definitions ● Delta: a single change [to a file] ● Changeset: a collection of deltas [perhaps to multiple files] that are collectively tracked. This captures a snapshot of the current state of the files [as a revision] ● Branch: Concurrent development paths for the same sources ● Merge: Joining changes done in multiple branches into a single path. ● Repository: collection of files we intend to keep track of.
    [Show full text]
  • Documentation for Fisheye 2.8 Documentation for Fisheye 2.8 2
    Documentation for FishEye 2.8 Documentation for FishEye 2.8 2 Contents Getting started . 8 Supported platforms . 8 End of Support Announcements for FishEye . 12 End of Support Announcement for IBM ClearCase . 14 End of Support Announcement for Internally Managed Repositories . 14 Installing FishEye on Windows . 16 Running FishEye as a Windows service . 19 Installing FishEye on Linux and Mac . 23 Starting to use FishEye . 26 Configuring JIRA Integration in the Setup Wizard . 31 Using FishEye . 38 Using the FishEye Screens . 39 Browsing through a repository . 41 Searching FishEye . 44 Viewing a File . 49 Viewing File Content . 50 Using Side by Side Diff View . 51 Viewing a File History . 53 Viewing the Changelog . 54 FishEye Charts . 56 Using Favourites in FishEye . 61 Changeset Discussions . 64 Viewing the commit graph for a repository . 64 Viewing People's Statistics . 68 Using smart commits . 70 Changing your User Profile . 75 Re-setting your password . 79 Antglob Reference Guide . 80 Date Expressions Reference Guide . 81 EyeQL Reference Guide . 82 Administering FishEye . 88 Managing your repositories . 89 Adding an External Repository . 91 CVS . 92 Git . 93 Mercurial . 96 Perforce . 98 Subversion . 101 SVN fisheye.access . 105 SVN tag and branch structure . 106 Adding an Internal Repository . 114 Enabling Repository Management in FishEye . 115 Creating Git Repositories . 117 Forking Git Repositories . 119 Deleting a Git Repository . 122 Setting up a Repository Client . 122 CVS Client . 122 Git Client . 122 Mercurial Client . 122 Perforce Client . 123 Subversion Client . 124 Native Subversion Client . 124 SVNkit Client . 126 Re-indexing your Repository . 126 Repository Options . 128 Authentication . 130 Created by Atlassian in 2012.
    [Show full text]
  • Collaborative Software Development
    Software development • Several users work on a same project – Remote or collocated users – Each one works on its own computer Groupware and Collaborative Interaction (asynchronous) Collaborative Software Development • Work on different tasks • Work at different times ! • Collaboration is hard to organize M2R Interaction - Université Paris-Sud - Année 2013-2014 Cédric Fleury ([email protected]) – Versioning, synchronization between users – Tasks distribution, social aspects Collaborative Software Development - M2R Interaction - Cédric Fleury !2 Outline Outline • Collaborative software development • Collaborative software development ! ! – Version control – Version control ! ! – Continuous integration – Continuous integration ! ! – Agile methods – Agile methods Collaborative Software Development - M2R Interaction - Cédric Fleury !3 Collaborative Software Development - M2R Interaction - Cédric Fleury !4 Version control Version control • Problematic • Problematic – We want to avoid this: – We want to avoid: • Manually share the files (USB key, email, Dropbox) • Delete or overwrite the files of other users • Broke all the project by making a mistake ! – We want to able to: • Edit the project at the same time • Keep an history of the modification • Keep the older version of the files + hierarchy [“Piled Higher and Deeper” by Jorge Cham: www.phdcomics.com] Collaborative Software Development - M2R Interaction - Cédric Fleury !5 Collaborative Software Development - M2R Interaction - Cédric Fleury !6 Version control Version control • Version
    [Show full text]
  • Version Control Systems Keeping It All Together
    Version Control Systems Keeping it all together Teammates working on software need: ◦Sharing: keep the code in one place ◦Concurrent Editing: work at the same time ◦Revert: undo changes to a working state ◦History: to understand what has been done Version control systems provide all of these Consider the alternative Shared File system Consider the alternative Shared file system (e.g. NFS) only keeps the most recent version Okay… locking? Another alternative: ◦Disallow concurrent editing at the file level ◦Lock the file, work, then unlock. Still not ideal ◦Not good for working on the same code – too much coordination ◦Or, nobody looks at each other’s codes ◦Need to wait on people to unlock ◦What if you forget to lock? Completely Synchronous? How about a Google Docs approach? ◦Everyone is editing the same code at once ◦Changes are seen immediately. Nope ◦Code needs to compile. Other people will break your code immediately. ◦Still can’t work concurrently The Version Control Way Copy, Modify, Merge Take from the repository Make your changes Merge your work with the repository No conflicts: Most merges are trivial ◦(i.e. nobody else was working) ◦Conflicts: Tools can help the merge process ◦(i.e. incorporate other peoples’ changes) Merging is much easier than you think. Popular Version Control Systems Subversion ◦Central repository ◦Still commonly used today Git (we’ll use this) ◦Hottest today. Very good, but a bit advanced… ◦No central repository – everyone has the repo ◦Merging and branching is even easier Mercurial, BitKeeper, Bazaar, SourceSafe, ClearCase, CVS, RCS Coordinated Changes are: managed and agreed upon chg1 chgN Release1 chg1 chgN Release2 etc.
    [Show full text]
  • Automating the Software Deployment Lifecycle with Chocolatey, Jenkins and Powershell
    Automating the Software Deployment Lifecycle with Chocolatey, Jenkins and PowerShell Paul Broadwith @pauby https://blog.pauby.com Who Am I? • Paul Broadwith, Glasgow, Scotland • 25+ years in defence, government, financial sectors • Lead Engineer on Boxstarter and Chocolatey cChoco DSC Resource @pauby 2 @pauby 3 Agenda • What is Chocolatey? • Chocolatey Sources; • Internalizing packages; • Recommended Organizational Architecture; • Common scenarios where Chocolatey automation will help you; • Based on a blog post https://blog.pauby.com/post/getting-started-with-chocolatey- and-jenkins/ @pauby 4 Before We Start! C4B @pauby 5 What Is Chocolatey? @pauby 6 A Definition Of Chocolatey Chocolatey is a package manager for Windows, like apt-get or yum but for Windows. It was designed to be a decentralized framework for quickly installing applications and tools that you need. It is built on the NuGet infrastructure currently using PowerShell as its focus for delivering packages from the distros to your door, err computer. @pauby 7 @pauby 8 Chocolatey manages Packages Packages manage Installers @pauby 9 Chocolatey Package Sources Where do packages come from? @pauby 10 Chocolatey Sources • Where packages come from; • C4B comes with two Chocolatey sources by default: • chocolatey – Chocolatey Community Repository • Chocolatey.licensed - Chocolatey Community Repository cached binaries; • Add your own sources: • Repository manager: Artifactory, Nexus, ProGet • Local folder @pauby 11 Demo 1 Chocolatey Sources. @pauby 12 Internalizing Packages Keeping it in the family. @pauby 13 Why Internalize Packages? • What is ‘package internalization’? • Organizations recommended to disable the default sources. • Reliability • Trust • Bandwidth • Copyright Restrictions • Using the default chocolatey source is subject to: • rate limiting; • excessive download limiting; @pauby 14 C4B Package Internalizer • Automatically internalizes the vast majority of packages; • Very fast; • Don’t reinvent the wheel; • Automation! @pauby 15 Demo 2 Package Internalization.
    [Show full text]