Continuous Delivery Workshop - Setting up Deployment Pipeline

It does not matter how good our design or architecture is, at the end of the day what matters is whether our code is ready for production. But the question is, how do we make sure that our code is always production ready. As described by Jez Humble [Co-author of Continuous Delivery book] Continuous Delivery [CD] is fast, automated feedback for production readiness of our code when any change that happens to the code, Database, configurations or the infrastructure.

During this workshop, we will give you an overview of Continuous Integration[CI] and Continuous Delivery[CD] and also talk about the key practices of CD such as:

  • Mainline Development
  • Feature Toggles
  • Build Automation
  • Deployment Automation

As this will be a “hands-on” session, we will be using Jenkins as an example tool. We will walk you through setting up CD using Jenkins and its Build Pipeline Plugin. We will also briefly touch upon open source tools that help with deployment automation such as Chef/Puppet, Capistrano etc.

 

 
10 favorite thumb_down thumb_up 6 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

The workshop will give an overview of:

  • What is Continuous Integration [CI]?
  • What is Continuous Delivery [CD]?
  • What is Deployment Pipeline  
  • Setting up a sample Deployment Pipeline using Jenkins Build Pipeline plugin
  • Overview of the CD practices such as:
    • Mainline Development
    • Feature Toggles

Learning Outcome

At the end of the session we expect the audience to takeaway the following:

  • Importance of “Continuous Delivery”
  • How to get started with “Continuous Delivery”
  • Kickstart steps for setting up a deployment pipeline

Target Audience

Architects, Programmers, DevOps

schedule Submitted 3 years ago

Comments Subscribe to Comments

comment Comment on this Proposal
  • Naresh Jain
    By Naresh Jain  ~  3 years ago
    reply Reply

    Hi Leena,

    Thanks for the proposal. It looks very difficult to give 90 mins to this session. Would it be possible to change the structure a bit so that this can be covered in 45 mins?

    • Leena S N
      By Leena S N  ~  3 years ago
      reply Reply

      Hi Naresh,

      Thanks for your comments. I am planning for a more hands on  session focussed on practices and thats the reason the proposal was for 90 minutes. 

      Am not sure whether we can do a good hands on session in 45 minutes, then the other option is to convert this to a talk which is not a "bit" but a "huge" change in my opinion.

      Please suggest us if you've any other ideas. 

      Thanks,

      Leena

      • Naresh Jain
        By Naresh Jain  ~  3 years ago
        reply Reply

        Just thinking out loud here: Can you make the VM available online so that people can download it and play around with it. Then they come to your session to clarify doubts. In short turn it into a clinic rather than a workshop. 

        • Leena S N
          By Leena S N  ~  3 years ago
          reply Reply

          Hmm. May not be a bad idea. There are a couple of issues that are making me uncomforatble:

          • From my past experiences, there is a high probability that most people might turn without any prep making the "clinic" unviable
          • If there are no specific questions from the participants, it might turn into a very basic "Getting Started" session as I can't cover all the things that I've mentioned in the "overview" section in 45 minutes. Its doable, but value to the participants would be very low. I would prefer to do things well or not do it at all.

          This leaves us with only 2 options i.e.

          • Accommodate it as a 90 minute workshop session, so no changes for the current proposal
          • Convert it to a talk which can be accomodated in 45 minutes.

          The second will be a very different from what I've proposed here. I am open to doing it but I would need your help in proposing a theme.

           

  • Ravi Kumar
    By Ravi Kumar  ~  3 years ago
    reply Reply

    Hi Leena,

    My suggestions given that this is a beginers tutorial on CI/CD.

    1. Setup a VirtualBox or VMWare instances with pre-configured Jenkins and other tools on Dropbox, Github etc. for people to download and come with installations. This might just save a lot of time in troubleshooting initail teething issues etc.

    2. In the end talk a little about real world challenges of achieving CD from your experience.

     

    Best,

    Ravi

     

    • Leena S N
      By Leena S N  ~  3 years ago
      reply Reply

      Hi Ravi,

       

      Yes, we will definitely be using VirtualBox or VMVare, thats how we did the previous workshop.

       

      Will also talk about the challenges we experienced too. 

       

      Thanks,


  • Liked Joshua Kerievsky
    keyboard_arrow_down

    Joshua Kerievsky - Anzeneering

    Joshua Kerievsky
    Joshua Kerievsky
    CEO
    Industrial Logic Inc.
    schedule 2 years ago
    Sold Out!
    60 mins
    Keynote
    Beginner

    Anzen. It helped a 100-year-old, 60,000-person aluminum manufacturer regain its greatness. It powers the culture, operations and massive growth of an online artisan marketplace. It's the common denominator of every great Lean and Agile principle and practice. Anzen is the Japanese word for safety.

    Every day, your time, money, information, reputation, relationships and health are vulnerable. Anzeneers protect people from injuries, hazards or near-misses by establishing anzen in relationships, workspaces, codebases, contracts, processes, products and services.

    When anzen is present in a software product, everything just works: people regularly use and recommend the product; engineers modify it without fear; it contains few defects; it can be deployed with ease; it is immune from threats; and it helps protect the organization's finances, reputation and investors. Anzen is a gateway to habitual excellence.

    Anzeneers approach failure as an opportunity to introduce more anzen into their culture, practices, and tools.

    In this talk you will learn what anzen is, how it promotes safe risk taking, how to identify faux safety, when it can be taken too far, challenges of growing an anzen culture and what it means to be an Anzeneer.

  • Anand Bagmar
    Anand Bagmar
    Director - Quality
    Vuclip Inc.
    schedule 3 years ago
    Sold Out!
    45 mins
    Demonstration
    Intermediate

    The key objectives of organizations is to provide / derive value from the products / services they offer. To achieve this, they need to be able to deliver their offerings in the quickest time possible, and of good quality!
    In order for these organizations to to understand the quality / health of their products at a quick glance, typically a team of people scramble to collate and collect the information manually needed to get a sense of quality about the products they support. All this is done manually.


    So in the fast moving environment, where CI (Continuous Integration) and CD (Continuous Delivery) are now a necessity and not a luxury, how can teams take decisions if the product is ready to be deployed to the next environment or not?

    Test Automation across all layers of the Test Pyramid is one of the first building blocks to ensure the team gets quick feedback into the health of the product-under-test.

    The next set of questions are:
        •    How can you collate this information in a meaningful fashion to determine - yes, my code is ready to be promoted from one environment to the next?
        •    How can you know if the product is ready to go 'live'?
        •    What is the health of you product portfolio at any point in time?
        •    Can you identify patterns and do quick analysis of the test results to help in root-cause-analysis for issues that have happened over a period of time in making better decisions to better the quality of your product(s)?

    The current set of tools are limited and fail to give the holistic picture of quality and health, across the life-cycle of the products.
    The solution - TTA - Test Trend Analyzer

    TTA is an open source product that becomes the source of information to give you real-time and visual insights into the health of the product portfolio using the Test Automation results, in form of Trends, Comparative Analysis, Failure Analysis and Functional Performance Benchmarking. This allows teams to take decisions on the product deployment to the next level using actual data points, instead of 'gut-feel' based decisions.

    There are 2 sets of audience who will benefit from TTA:
    1. Management - who want to know in real time what is the latest state of test execution trends across their product portfolios / projects. Also, they can use the data represented in the trend analysis views to make more informed decisions on which products / projects they need to focus more or less. Views like Test Pyramid View, Comparative Analysis help looking at results over a period of time, and using that as a data point to identify trends.

    2. Team Members (developers / testers) - who want to do quick test failure analysis to get to the root cause analysis as quickly as possible. Some of the views - like Compare Runs, Failure Analysis, Test Execution Trend help the team on a day-to-day basis.

    NOTE: TTA does not claim to give answers to the potential problems. It gives a visual representation of test execution results in different formats which allow team members / management to have more focussed conversations based on data points.

  • Liked Sunil Mundra
    keyboard_arrow_down

    Sunil Mundra - Getting A Partner To Adopt Agile

    Sunil Mundra
    Sunil Mundra
    Principal Consultant
    ThoughtWorks
    schedule 3 years ago
    Sold Out!
    20 mins
    Case Study
    Intermediate

    Due to the business benefits which accrue from Agile, clients are demanding their IT Departments/Partners to adopt Agile. It is quite common to find a situation where the client has adopted Agile, but its Partner/Vendor has not.


    This talk is based on my consulting engagement with a client who had adopted Agile and their partner had not, and the client wanted the partner to Adopt Agile.


    The talk will cover the critical challenges encountered in getting the partner to adopt Agile, especially given the wide difference in cultures of both organizations and also the organizations being located in different continents. The talk will also cover the key learnings from this journey.

  • Liked Shirish Padalkar
    keyboard_arrow_down

    Shirish Padalkar - Application Security - The Agile Way

    Shirish Padalkar
    Shirish Padalkar
    Senior Consultant
    ThoughtWorks
    schedule 3 years ago
    Sold Out!
    45 mins
    Talk
    Beginner

    Traditionally application security has involved upfront design and a big bang penetration test after development. This leads to the phenomenon of “bolt-on” security that translates into increased cost and complexity.

    Drawing on our experience on real-world projects, we show how security can be baked-in on an agile project. Using case studies we demonstrate how security concerns are captured during project inceptions, how developers write secure code, security testing is automated and how configuration management can help achieve secure deployments. This talk introduces several new concepts like secure by design, secure design patterns and lightweight code reviews.

  • Liked Anand Bagmar
    keyboard_arrow_down

    Anand Bagmar - The Agile “Chalta-Hai (It’s OK)” Manifesto

    Anand Bagmar
    Anand Bagmar
    Director - Quality
    Vuclip Inc.
    schedule 3 years ago
    Sold Out!
    45 mins
    Experience Report
    Intermediate

    The Agile Manifesto was formulated by 17 people in 2001. We know the principles of the Agile Manifesto … but do we really understand it?

    Depending on the organisation culture, the team culture and various other factors, they reach varying levels of Agile adoption. Martin Fowler talks about the levels of adoption and the path to get better via his post on “Your Path through Agile Fluency”.

    Not surprisingly, not all Agile project implementations are successful.

    This session is going to take you through a journey to talk about some of the Myths of Agile and also behaviors that inhibit organisations and teams to reach great(er) heights in Agile Fluency to achieve Agile’s benefits.  As a result, the Agile Manifesto has remained on paper, but teams have come up with their own ‘workarounds’ - which are not truly solutions to solve a complex problem well.

    We accept it because of our “chalta-hai (it’s ok)" attitude. At the end, what are we then left with? The Agile “Chalta-Hai (It's OK)” Manifesto.

  • Liked Unmesh Joshi
    keyboard_arrow_down

    Unmesh Joshi - Organizational Patterns

    Unmesh Joshi
    Unmesh Joshi
    Application Developer
    ThoughtWorks
    schedule 3 years ago
    Sold Out!
    45 mins
    Talk
    Advanced

    Organizational Patterns study by Jim Coplien done throughout 90s forms the foundation of Agile. Its important to understand these patterns and go beyond  'popular practices' like stand ups, user stories and TDD. Individuals are important and there are certain characteristics of these individuals which makes a team Agile or not. This presentation covers some of the very important patterns which form the basis of Agile, without these, any Agile project is bound to fail.

    Jeff Sutherland, creator of scrum, now actively uses Organizational patterns to explain acrum and also started an effort at www.scrumplop.com to collect patterns which make Scrum work.

  • Liked Pankaj Kanchankar
    keyboard_arrow_down

    Pankaj Kanchankar - Line Managers - an Endangered Species in Agile

    Pankaj Kanchankar
    Pankaj Kanchankar
    Agile Coach
    ThoughtWorks
    schedule 3 years ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    The matrix organization of yore relied on maximizing returns on each skillset. This lead to having line managers and practice horizontals.
    Engineering managers looking after developers and practice managers looking after the respective practices of BA, QA and PMO. This lead to having multiple lines of reporting for team member whilst on the project.
    In Agile teams, focus is on the self organising teams of empowered employees working towards common success criteria (project success is team success). Not everyone can be a PO or a Scrum Master. So is the role of so called line managers or practice managers become redundant?
    Whats their role in the agile teams?
    How their role needs to transform

    In this talk I will be addressing these questions. Bring out how some of their responsibilities are now taken up by the team or Product Owner or Scrum Master. I will also be suggesting how line managers can take this as an opportunity to morph into more meaningful roles that help the organization and teams. 


  • Liked Om Prakash Bang
    keyboard_arrow_down

    Om Prakash Bang - Writing Excellent Requirements in agile way

    90 mins
    Workshop
    Intermediate

    Traditionally Project Manager was playing a role of Business Analyst in a small and medium organizations.  Leading organization have come to understand that Business Analyst as a separate role is critical for success of a project.  As organizations are undergoing agile transformation and adoption, role of business analyst need to be redefined. What are the different options for Business Analyst in scrum; Partner with Product Owner?  Transition to Product Owner?  Part of Agile Team? What are the characteristics of agile BA? The core activities, skills remain same, but the way they perform differs.

    This presentation is to give walkthrough on

    • Role of Business Analyst in agile
    • Progressive elaboration of Product Backlog Items / Feature / User Stories
    • Requirement communication in agile
    • Quality of Product Backlog Items / Features / User Stories
    • Factors in writing excellent requirements 

    Why product backlog refinement is important for the success of agile project? How it improves productivity of team?  What should be the writing style and how much level of details is good enough. The session also includes 30 - 45 Minutes of workshop on requirement elicitation.

  • Liked Sridharan Vembu
    keyboard_arrow_down

    Sridharan Vembu - Turning around a twice-failed distributed enterprise program into success

    45 mins
    Experience Report
    Intermediate

    The common myth about agile methodology is, it is suited for smaller, co-located teams, would not scale up for big enterprises and is best suited for smaller, less complex programs.

    In this talk, I intend to share how we went about setting up, executing and successfully delivering probably one of the most complex and strategic programs for one of our customers. This program was the first ever successful adoption of the fully distributed agile implementations for the customer.

    Context: The client is the leading Telecom Operator in the UK, having their captive and other strategic partners based out of India. The program was highly strategic for the client and the predicted ROI was high.

     - The implementation was tried twice by different vendors for more than an year, but failed to deliver; root causes were not analyzed

     - The Program Sponsor had one last chance to try and deliver the platform successfully, against a very tight schedule

     - Continued Operational risk with the legacy system in place 

    Outcome of our engagement:

     - Core functional application ready in pre-production by the end of first release cycle (4 months from engagement start); fully ready to functionally scale easily and quickly

     - Adoption of the technical and execution approach to other related programs within the portfolio 

    Our Approach:

     - Outcome of initial assessment of the existing codebase was to go with re-write from scratch; was a really hard sell, but was the RIGHT thing to do

     - Re-define the release cycle: extend development period by embedding integration testing as part of development cycle and cut down on the low level design phase

     - Need-basis colocation of functional SMEs with development team 

     - Direct access to Product Owners: weekly video calls, must-attend iteration show-cases, etc

     - Remove unnecessary operational overheads, in terms of people as well as organizational processes

     - Well-defined, pragmatic strategy for Integration testing (major constraints - lead time for test data preparation, limitation in re-usability of test data, lack of e2e functional understanding within team)

      - Smart seeding of other vendor team members (with good functional/domain understanding) into the core team

      - Zero compromise on basic hygienic practices: IPMs, Showcases, communicate negative-news-first with alternate solutions/workarounds, strict removal of wastes, inclusive decision making, highest degree of code coverage, sanity test suite, e2e basic automation suite   

      - Building trust between distributed teams: cross-pairing, align on core work hours across time zones, joint showcases and retrospectives (shared responsibility)

    Challenges faced:

      - Big push to release the core functional platform into production in 3 months (immediate next release)

      - Working out of other vendor premises: seen as threat to their business, lack of cooperation and collaboration   

      - Product Owners based out of UK, no easy / frequent access

      - Functional SMEs/designers based out of different location

      - Release cycle that was in place: 8 weeks of design, 4 weeks of development and 8 weeks of testing!

      - Distributed and isolated testing teams

      - Highly manual and time-consuming E2E testing processes

      - Multiple interfacing systems, both upstream and downstream 

      - Client development team based out of UK, different execution approach, lack of trust between the teams

    In summary, I would like to share the unique aspects of the execution approach that made this program a real success for the customer, though some of the approaches might be tried out in different environments and project situations.

  • Liked Khaarthigha S
    keyboard_arrow_down

    Khaarthigha S - Scaling Agile For Enterprises with Distributed Engagement Models

    45 mins
    Case Study
    Advanced

    I would like to share my experience in consulting and managing a distributed team - Identification of strategies for a transformation of "a lifeless program to a Successful Program " and journey from "Collective Inception to Collective delivery" 

    This becomes challenging especially with a complicated -distributed engagement model for our client which is a reputed and huge enterprise with presence in every corner of the world.

    In a complete globalized world, the major bottleneck for a huge enterprise is the effective functioning of globally distributed teams despite using Agile,lean.

    In my presentation, I am going to share the approaches that we tried to address the pain points including the following:

    1. Not even able to plan the Iteration planning meeting - Iteration planning not producing the outcome despite hours of planning meeting
    2. Manage dependencies between teams for a collective delivery
    3. Communication channel between teams  (Change how you communicate/coordinate)
    4. To bring the organic coherence between teams despite the cultural difference
    5. To also worry about the unknown interfaces & disastrous scenarios
    6. Different team communities with different process and practices impacting the other team’s delivery
    7. To sustain the work ecosystem for all the teams
    8. Inoffensive collective Retrospective for a constructive learning
    9. Major Natural pain point – “its not the distance, it’s the time zones”
    10. Above all, Conflict Resolution

    Eg: one part of approach which we tried was "Mountaineer-Diver Model". 

     

    Impacts of above are listed below:

    • Dynamic Dependecy resolution between teams ( instead of long hours of call for each dependency)
    • Collective , Objective planning for all the teams by matching the dependencies so that the delivery is not affected and also "All teams walking in same speed"
    • More common understanding and project focus in all teams (Frustration with the team members reduced)
    • All members from different teams directly interact and work even they are distributed ( as they spend some time physically working together as "integration teams")
    • As a result of above -> 2 key metrics improved :
      • Velocity of all teams improved
      • Development and Testing complete even before the deadline -> Delivery before the scheduled date
      • Very less time spent in meetings for conflict & dependency resolutions, planning , etc.. 

     "Project execution was the key success". 

    This will help in approaching the issues pragmatically , dynamically and also help understand how its better to make a hybrid out of multiple tools rather than using only one single process tool.