Confused about Continuous Integration vs Delivery vs Deployment? Not sure how to take the next step towards Continuous Deployment?

In this session, Nayan will remove the confusion around the "Continuous" terms. He'll then show you how to go from Commit to Production with no manual steps, while remaining confident that your production system remains stable. We will do this with a variety of open source tools -- from traditional build & integration tools to modern deployment environments & monitoring. You'll leave the session inspired and ready to build your own Continuous Deployment Pipeline when you get back to work.

 
2 favorite thumb_down thumb_up 0 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

I - Overview of "Continuous" terms - 10 minutes

II - Demo of building CD Pipeline - 50 minutes

Throughout part II, I will be engaging the audience with discussion questions and soliciting input on next steps.

 

Learning Outcome

  • Knowledge of Continuous Deployment tooling
  • Reduction in fear around "where do I start?"
  • Confidence to build a CD pipeline

Target Audience

Anyone interested in Continuous Deployment

schedule Submitted 2 months ago

Comments Subscribe to Comments

comment Comment on this Proposal

  • Liked Gillian Lee
    keyboard_arrow_down

    Gillian Lee - Teams Want a Quick Game to Learn How to Deliver Value Faster

    75 mins
    Workshop
    Beginner

    Agile helps you to deliver what’s valuable to the customer faster. You can capture, prioritize, communicate, and deliver that value with good user stories. In our experience, a major impediment to writing good user stories in the real word is a lack of example stories. We have created a set of games that incorporate 80 examples of good and bad user stories. The games are easy to learn, play, and teach so that you can experience good user stories in just a few minutes. Come play the games and then share them with your friends and co-workers!

  • Liked Robert McCabe
    keyboard_arrow_down

    Robert McCabe - Getting Physical with Jira. Using a physical Kaban and Scrum boards with Jira.

    30 mins
    Experience Report
    Intermediate

    This session I will review how we used a physical Kaban board and post-it notes with Jira and the Agile Cards plugin to sort through a sea over 500 of Jira issues in various states of progress. The process was complicated by a large number of projects with inconsistent workflows and confusing states ("In Review" could mean in code review or in QA review). I will review how the team members worked to examine and group issues, place them into the right state, abandoning some, moving others to the back log and prioritizing the rest. I will also show how having a physical board change the nature of our stand-ups and how we updated Jira to match the board.

    (at the current time this is still a work in progress, but I will add to the presentation as we work towards a mature system. Update: I am no longer with the company I started this at and I did not get to complete migrating to a mature system, but I did learn some valuable lessons on the way.).

  • Liked Ranjith Tharayil
    keyboard_arrow_down

    Ranjith Tharayil - Change Vector Tracking in emergent design

    45 mins
    Talk
    Intermediate

    A reflective design approach to achieve software design agility by modelling change as a vector and tracking it to aid refactoring decisions.

     

    Preface about the talk

    Software design is a field that has always fascinated me and I have tried to be an obedient student trying to learn this art. Like any other design problem, software design is also a wicked problem. Horst Rittel and Melvin Webber defined a “wicked” problem as one that could be clearly defined only by solving it, or by solving part of it .This paradox implies, essentially, that you have to “solve” the problem once in order to clearly define it and then solve it again to create a solution that works.

    Hence you need an architect with magical powers to get your design correct in the first go .This is the core philosophy behind emergent design in which we do not think too much about future . As Uncle Bob sarcastically points out, your customers somehow knows your design and they will come up with a requirement that will break your assumptions and thus your design. In emergent design you embrace aggressive refactoring religiously and few teams rebelliously for the good. It has also been observed that during emergent design refactoring step more focus is towards class design than higher abstract architecture elements. This creates technical debt which can go unnoticed for a long time.

    In this talk I will be introducing a novel technique called change vector tracking that will address the above described problem. Change Vector Tracking is a reflective design approach to achieve software design agility by modelling change as a vector and tracking it through ceremonies like Change Vector Tracking meetings.

    Change vector tracking doesn’t prevent customers from coming up with requirements that would invalidate previous design assumptions, it helps us in monitoring these changes and aids in making informed decisions of where and when to redesign. It helps us keep a check on design debt which otherwise would be overseen and not addressed at the right time .Design debt is invisible to tools initially, only when it grows beyond a scale tools can catch it. Change vector tracking is a technique to capture this design debt in a very early stage. “A stitch in time saves nine”.

  • 45 mins
    Talk
    Intermediate

    Although self-organizing teams are crucial to carrying out a successful Agile transformation, organizations that implement Agile at scale invariably realize that the introduction of such teams forces the organization to re-engineer numerous aspects of its operating philosophy. In particular, various management layers are often removed. The individuals in these layers are routinely re-purposed or laid off.

    This talk highlights the approaches I used as an Agilist in various organizations to help people in different roles on their journey of transitioning into the world of Agile. Specifically, the talk will focus on 5 key roles: Project Managers, Product Managers, BA Managers, Development Managers, and QA Managers. It will provide insight into how managers can effectively transition to some of the new Agile roles, or redefine their existing role to effectively fit in an Agile world.

    The emphasis in this talk is on pragmatic strategies for managers that are struggling to find their place in this new Agile world. Armed with these strategies, participants will be able to effectively adapt to the Agile transformation, as well as discover potential new career paths for themselves and for the individuals reporting to them.

  • Liked Maurizio Mancini
    keyboard_arrow_down

    Maurizio Mancini - Scaling Quality by Building it in

    45 mins
    Talk
    Intermediate

    According to the 11th annual State of Agile report by VersionOne, one of the top five reasons for adopting Agile is to “enhance software quality”. In spite of this aspiration, a common pattern in Agile rollouts is the failure to set quality goal improvements from the outset. It is often assumed that if you implement Agile/Scrum then quality will just take care of itself. As many organizations quickly discover, you cannot just “deploy Agile” and expect it to be the silver bullet for a software organizations’ quality issues. Why is this happening so frequently? Is it due to methodical deficiencies, unrealistic expectations, fundamental misunderstanding of Agile, lack of executive support, too much existing technical debt or all of the above?

    If you are questioning whether your Agile rollout is really helping you deliver higher quality software, faster, then this talk is a must to attend. I will discuss the approach I have successfully used in a number of organizations which involves; identifying the necessary building blocks to establish a quality mindset in an organization, moving the organization to a test first mindset, helping the Product Management organization become more Agile, and finally setting the right level of test automation so that you can deliver quality software faster.

    If you are serious about doing Agility at scale, you cannot realistically achieve that goal without ensuring that each team individually delivers quality, and in-turn whole projects/programs that incorporate outputs from the individual teams are delivering quality software. To successfully scale quality, you will need to follow the ‘blueprint’ provided in this presentation.

  • Liked Daniel Doiron
    keyboard_arrow_down

    Daniel Doiron - OKALOA FLOW LAB

    Daniel Doiron
    Daniel Doiron
    President
    Agile Agonist
    schedule 3 months ago
    Sold Out!
    75 mins
    Workshop
    Executive

    This workshop can be given in either French or English ....

    Enterprise agility come in numerous flavors. Participants will be confronted with the false choices presented to them (Flow vs Iteration, feature teams or competence based) by different approaches and be better able to build bridges between islands of agility (Scrum, LeSS, SAFe, Kanban)

    The OKALOA FLOW LAB is a new simulation created by Patrick Steyaert, conceptor of Upstream Kanban, Discovery Kanban, Portfolio Kanban, Customer Kanban. He is a world leader in all matters related to agility.

    The simulation is fantastic.

  • Michael Ackerbauer
    Michael Ackerbauer
    Whole Team Evangelist
    IBM
    schedule 3 weeks ago
    Sold Out!
    75 mins
    Workshop
    Beginner

    Why do some Agile teams become shining innovators and others struggle? This workshop will guide teams to understand the natural elements and flow of team problem solving. They will learn techniques to tailor the process for each team’s members. By doing so, they will unlock the natural innovative nature of every team member and find the “wisdom of the crowd” — how the people on an Agile team can wring out every last ounce of their creative best in service to their projects and each other.

  • Liked Howard Deiner
    keyboard_arrow_down

    Howard Deiner - How We Get Agile Transformations Wrong By Trying to Do It All So Right

    60 mins
    Talk
    Intermediate

    Sorry to say it guys, but Agile has gone limp over the last few years.  As we get more and more coaches into the mix, both external as well as internal, organizations somehow have forgotten that it’s software that we’re trying to produce.  Not great stand-ups.

    Technical practices matter.  In fact, if we could dispense with ALL process and still create the valuable quality software that is needed, we should do that.  From a Lean perspective, process adds no customer facing value.  But getting rid of all process is crazy talk.  Even Fred George, who promoted “Programmer Anarchy” several years ago never got away from all process.  In reality, his movement was premised on driving business decision making directly into technical decision making, and completely empowering teams to “be” the company.  He premised the concept of “Programmer Anarchy” on using the best and brightest developers out there, and trusting that if they could do something as difficult as create great code that they could do the business decision making as well.

    But perhaps we don’t have the absolute best talent out there.  Perhaps it’s hard to lure people away from Google and Facebook because of the money and the chance to get great work environment and unbelievable work challenges (change the world, anyone?)  Does that mean that we have to go back into the Fredrick Winslow Taylor world view of “The One Best Way”?  With that way becoming making a choice between Scrum, SAFe, Lean/Kanban, and other development processes?

    I’d like to convince you that what’s going to work for your organization and your employees is something in the middle.  I, of course, lean into the “better technical practices will yield better outcomes” frame of mind.  You may as well.  But when Garrison Keillor said, on “A Prairie Home Companion” (a long running radio show on National Public Radio in the States), “Well, that's the news from Lake Wobegon, where all the women are strong, all the men are good looking, and all the children are above average”, that was satire!  And the same is true of your organization.  It can logically be true that all organizations’ developers are all above average.  But we can hold people to an acceptable level of technical practices that will yield in writing better code than merely having a process that talks about writing better code. 

    This session will speak to the specifics of the whats and whys.

  • Liked Eric Lessard
    keyboard_arrow_down

    Eric Lessard - Fast Inception: Why it matters and how to achieve it

    Eric Lessard
    Eric Lessard
    Agile Coach
    Facilité
    schedule 3 weeks ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    As agility spreads across organisations, the agile practices regarding execution have grown more mature and reliable. The inception phase of projects, however, remains challenging to many agile practitionners. For a long time, we pursued balance between a reckless all-in approach or a long and tedious path through stage gates and chains of approval. As a solution to these concerns, we came up with a path we refer to as the Fast Inception. This path, built with a dense and intense agenda collaborative workshops, is bound to provide a both shorter and safer way to bootsrap your project.

  • Liked Juan Silva
    keyboard_arrow_down

    Juan Silva - Agile Estimation: The battle between Points and Hours in a services agency world

    30 mins
    Talk
    Beginner

    When you learn about agile practices, one of the most challenging concepts to grasp is Story Point Estimation. This is particularly true for service companies that normally bill clients by the hour.

    On the one hand, they need to submit project proposals that are based on concrete time estimates.

    Story points, on the other hand, are an abstract concept by design. They were born out of the needs of product companies with the purpose of having a better assessment of the amount of work involved in developing software units, regardless of how long each unit takes. This makes people struggle between using points and hours. You want to reap the benefits of point estimates, but you still want to keep things tied to time.

    In this session, I will introduce the notion of point estimates, highlighting its advantages over hour estimation. Then I will explain one approach to doing point estimation in a professional services company. I will address common concern from various stakeholders from Project Management to Business Development, COOs and CEOs.

  • Liked Stacey Vetzal
    keyboard_arrow_down

    Stacey Vetzal - Strengthening Shared Team Values Through the Four Rules of Simple Design

    60 mins
    Talk
    Intermediate

    Over the past few years, I’ve found incredible flexibility in building my technical coaching practice around the "Four Rules of Simple Design", originally penned by Kent Beck back in the ‘90s.

    The Four "Rules" have resonated with many developers over the years, and have a wonderful lack of specificity. These tiny pearls of wisdom are so simple and flexible that they have caused many an argument. They have even been called generative – that is we can derive many of our practices and small-scale architecture by extrapolating on them.

    As such, they provide fertile grounds for growing consensus on the thousands of decisions your team should be making together.

    1. Tests Pass – How does your team test the code you deliver, and at what level(s) of abstraction will you decide to test?
    2. Express Intent – How does your team arrive and socialize common understanding so that the intent in your code is always clear to every team member?
    3. Don’t Repeat Yourself – What strategies do you use to ensure your team knows what behaviour is present in your code, and how to leverage it without duplication?
    4. Small - What dimensions will you measure so that you continue to derive the maximum level of value from a minimal amount of code?

    Code that follows these rules has a natural agility. Tests give us confidence to make change. Clear intent helps us find what needs to change. No duplication means we make the change only once. Small means we aren't getting lost on our way to making the change, and allows us to make more meaningful change with less effort.

  • Liked Lisa Fast
    keyboard_arrow_down

    Lisa Fast - Not too minimal: UX research in a Government MVP

    Lisa Fast
    Lisa Fast
    UX Unicorn
    Vation Inc.
    schedule 1 month ago
    Sold Out!
    30 mins
    Talk
    Beginner

    Lean UX research is essential to guide and validate what exactly is the 'Minimum Viable' to launch a Minimum Viable Product, especially in government.

    In this talk, I'll describe how user research insights helped us understand, design and launch Canada's first online open-source regulatory consultation. The first research participant identified a significant hole in our assumptions - and predicted that we could miss the minimum viable mark. It helped us course-correct, and plan ahead for the next development iteration.

    The other customer group was the government. We applied lean UX research techniques to understand the government analyst team's journey and needs, and then to co-design with them as the analysis site MVP was developed, and as the commenter data flowed in.

    I'll describe how the insights from the research helped us meet the Minimum Viable mark for the government customers, understand how and why we missed the mark with the specialist customers and how you can apply lean UX research techniques to ensure you don't iterate your way to a useless product.

  • 45 mins
    Talk
    Executive

    In the federal public service there is an air gap between the performance evaluation criteria applied to business leaders and the criteria applied to service providers.

    As a consequence, even in situations where both the business and the service provider enjoy optimal relationships, the goals are not the same and may even be contradictory.

    In a climate centered on Results and Delivery, leaders cannot expect results if they do not tackle this conflict.

    The approaches proposed in this discussion align the service organization to the business. They promote mutual accountability by insisting on mutual performance alignment between the business and its services provider.

  • 60 mins
    Talk
    Intermediate

    In today’s fast paced world, we in the Agile community have gotten better at organizing and prioritizing work. We have learned how to focus on high value and eliminate waste in our processes. And yet so much of Agile these days is focused on how we move work from an idea to production while ignoring or undervaluing how to build high quality working software. Our focus is on how to hold retrospectives, collaborate with product owners, and hold daily standups but very little attention has been paid to how we write and test code. This puts your business at risk.

    Join Cheezy as he talks about how we often miss the target in our “Agile Implementations”. Instead, he will challenge us to focus on technical excellence as the true Path to Agility. His lightweight approach for teams to deliver software with Zero Defects strips most methodologies down to their bare essence. This allows teams to focus on what is really important - rapidly delivering working software to customers. If you’re ready to take the next step in your agile journey then you won’t want to miss this talk.

  • Liked Dave Dame
    keyboard_arrow_down

    Dave Dame / Aaron Sampson, PMI-ACP, ITILv3, SMC - Design thinking and Agile: Infinitely more powerful together

    45 mins
    Talk
    Intermediate

    When Agile first came on the scene it was premised around putting the customer first. But, over the years its focus has evolved and the general perception of Agile today is that it’s mostly a tool for delivering software. Agile’s original focus was mainly on developers and testers, but it never really contemplated design thinking as a discipline. Design thinking, which has been around for decades but is only recently having its ‘moment in the sun’, compliments agile beautifully in that it focuses on trying to solve the right problems for the right people. Design thinking allows us to iterate and test assumptions before too much coding and production-readiness is done, which helps ensure the team is investing in the right things at every stage. It really provides a focus on innovating rather than simply burning down a backlog. In this talk we will discuss different ways to incorporate design thinking into the agile process. You will learn how to yield benefits from bringing these two practices together – most importantly how to best serve the users of the product or service you are delivering. At Scotiabank, we’ve been using these fantastic tools in combination for over a year. It is a journey, and although we haven’t completely solved everything yet, there are a lot of lessons we have learned that can be applied elsewhere.

  • Liked Nancy Wu
    keyboard_arrow_down

    Nancy Wu / Sriram Natesan - Every product tells a story. What does yours say?

    75 mins
    Workshop
    Beginner

    As a Product Owner, I am sure this has happened to you. You worked with a team on an initiative and it resulted in something different than your vision. The customer was not happy, you were not happy and the team felt they had done everything that was asked.

    How do we change this? How do we build a common understanding around the product vision?

    User Story Mapping is one of the tools that can help bridge the gap from idea to fruition. Story Mapping can be applied to software development and real life situations. It requires only a few simple ingredients: user personas, customer journey and clear outcomes. This will provide a basis to discuss, prioritize and slice your backlog. Story Maps are a great way to guide a team to quickly creating a minimal viable product and validate the solution fit.

    When I was a product owner, I have created story maps on initiative, portfolio, feature levels of my product. They have helped articulate my vision with the team, and the team refined the product vision.

    In this session, we will create a Story Map, leverage tools and techniques like empathy map, Kano model and MoSCoW to slice backlogs and most importantly tell your story. This workshop will hopefully help Product Owners and teams to focus on the user's journey.

  • Liked Sriram Natesan
    keyboard_arrow_down

    Sriram Natesan / Pradeep Nadgir - Is Agile Working?

    60 mins
    Talk
    Intermediate

    Large companies (Banks, Insurance, and Telecom) in our community have been on their Agile Transformation journey over the past 4 to 5 years, implementing Agile in various pockets of the organization. Leaders have made significant investments of time and money on this journey and are now facing the challenge of articulating tangible benefits of the transformation and would like to measure the efficacy of the transformation.

    Basically, they are asking Is Agile Working?

    While there is no one simple answer to this seemingly innocuous question, we have from our experience working with these different clients devised a process that has helped us with answering this question.

    In this session, we would like to share the three step process which we hope will help you.

    • Firstly, we start with identifying the personas in the organization who are asking the question. And in our experience, we have identified (at least) four major personas that work for this scenario.
    • Secondly, we identify the business objectives and outcomes that these personas want to achieve. This involves multiple workshops and sessions with these personas to identify their objectives and outcomes.
    • Finally, we introduce a 3 * 3 matrix based on the organization lens (personas) and the maturity of Agile capabilities in the organization

    The three step process identified above has proven to work irrespective of the industry it is being used in and provides a comprehensive and structured way to answer the important questions that an organization faces during the transformation. This process and the accompanying tool provided enable executives to make data backed decisions on the areas to focus on next in the transformation.

  • Liked Ron Ijack
    keyboard_arrow_down

    Ron Ijack - Why we got rid of SCRUM to become agile again

    Ron Ijack
    Ron Ijack
    VP Technology
    Upstream Works Software
    schedule 1 month ago
    Sold Out!
    30 mins
    Talk
    Advanced

    Agile is not about doing scrum, kanban, lean or any other flavour of the process. An organization cannot be “doing” agile, they must “be” agile. They must believe in and understand the agile principles. After going through a successful agile transformation and running scrum for 3 years we realized that it’s just not working for us anymore. The team was suffering from scrum fatigue. It felt like there was a sprint planning, stand up or retrospective meeting happening all the time. We decided to take a hard look at how we were working and turn it on its head. We looked at all the different agile options such as scrum, kanban, lean, xp, etc and decided to take the best part from all of these instead of sticking with one approach. This session will take you through our journey and share what worked for us that could also work in your organization

  • Liked Steve Lavigne
    keyboard_arrow_down

    Steve Lavigne - Our Digital Transformation to Agile, Challenges and Insights

    Steve Lavigne
    Steve Lavigne
    Product Owner
    OPIN Software Inc.
    schedule 3 weeks ago
    Sold Out!
    60 mins
    Experience Report
    Beginner

    This is a new presentation with the goal of sharing our lessons learned in the adoption of an agile project management approach, with a focus on Scrum, within our web development (Drupal) agency.

    The rules and practices for Scrum - a simple process for managing complex projects - are few, straightforward, and easy to learn. But Scrum’s simplicity itself - its lack of prescription - can be disarming, and new practitioners often find themselves reverting to old project management habits and tools and yielding lesser results.