location_city Bengaluru schedule Mar 22nd 03:00 - 03:20 PM place Grand Ball Room 2 people 55 Interested

With the move to microservices architecture, a lot of teams end up managing dozens of code repositories (vs just a couple before), and some tasks that were done quickly manually are now becoming very time consuming : consistency of the repositories, and eventually of your platform, gets impacted, making it more and more difficult to manage.

Surely, there must be some tools existing to take care of boring tasks like finding where a given dependency is used, and upgrade it automatically (this is just an example)... Well actually, we didn't find anything, so we implemented them ourselves and made them available for everyone !


Outline/Structure of the Demonstration

After a brief introduction explaining the operational challenges of microservices, we'll quickly switch to the demo of the 2 tools I have implemented and open-sourced :

- https://github.com/societe-generale/github-crawler gives you an up to date view of your repositories portfolio : what versions we're using (lib, Docker image, anything), what Jenkinsfile var is used, we can pretty much monitor everything that is relevant to our context.

- https://github.com/societe-generale/ci-droid has one feature that enables to replicate smartly the same change automatically in any number of repositories.

We will see together a couple of use cases, and how these tools can help you make the right decisions, what to take into considerations before making a change "at scale", and how to perform the change in less than 2 minutes.

Learning Outcome

After attending the session, people who are managing more than 10 code repositories will be relieved to know that they don't need to spend hours on boring tasks anymore : rebasing mergeable pull requests is now automated instantly, notifications when a pull request has conflicts are sent, and custom basic review comments are given few seconds after the pull request is created. But that's not all ! Now, getting a clear/accurate characteritics that matter to you, and replicating changes all over them will now take few minutes !

And since both tools have been designed for extensibility, maybe you'll veen want to contribute to improve them !

Target Audience

devops engineers, platform CTOs, anyone "doing" microservices, managers looking for efficiency levers, opensource geeks

Prerequisites for Attendees

no prerequisite - if you have a laptop, you can browse the source code of the tools I'll be presenting on github.com



schedule Submitted 2 years ago

Public Feedback

    • Rashina Hoda

      Rashina Hoda - Becoming Agile vs Doing Agile (Research Talk)

      45 Mins

      After 20 years since the manifesto, the latest state of agile reports more than 80% of organizations as "still maturing" in their agile practice. As agile methods expand beyond small teams and software itself, we are still struggling to answer these questions:

      • Why is it that some teams are more 'agile' than others even though they all claim to be practicing agile methods?
      • What all dimensions need to change as teams, managers, and entire organizations attempt to become agile?
      • How do these dimensions interact with each other?
      • Overall, what does it take to become agile and how does that differ from doing agile?

      This talk is based on my original theory of becoming agile developed from 10+ years of industrial research of agile practice in New Zealand and India, which received the distinguished paper award at the IEEE/ACM international conference on software engineering (ICSE), in 2017.

      In this session, I will explain the key dimensions that need to transition during agile transformations, using industrial examples, and highlight what you can do to progress beyond simply doing agile, to harness the most from your agile transformations.

      This keynote will add a unique research perspective to the conference program, sharing agile research in an industry-friendly format and delivery style.

    • Tobias Anderberg
      Tobias Anderberg
      Agical AB
      schedule 2 years ago
      Sold Out!
      45 Mins

      Ever wondered why some people prefer to work alone? Or why some people cringe when pair programming is mentioned? It might be that that person, like me, is an introvert. But is is really that simple? Can we really put every person in a box labeled "introvert" or "extrovert" or are we all just ambiverts?

      During this session I will talk about introverts, extroverts and everything in between.
      Drawing from almost 15 years of personal experience being an introvert on agile teams I will talk about the differences of being an extrovert
      or an introvert, how to foster an inclusive team environment, and the importance of psychological safety.
      You will hopefully leave this session better fit to help EVERYONE on your team to reach their full potential!

    • Jutta Eckstein

      Jutta Eckstein - CD – Continuous Delivery and Cultural Difference

      20 Mins

      DevOps and continuous delivery is typically elaborated technically - what kind of tools, technologies, or skills are necessary for being able to deliver continuously. Often it is forgotten that continuous delivery requires also a culture change - in development, operations, marketing, sales, and not least for the customer.

      This can be recognized for example, that although it is technically possible for a team to deliver continuously, but it seems that this delivery isn't welcomed. This means the actual system will not be directly used.

      Therefore, in this session by taking into account the necessary cultural change, I want to answer the question how to implement continuous delivery successfully and what kind of pitfalls you need to be aware of when doing so.

    • Gabor Devenyi

      Gabor Devenyi / Alex Sloley - The magic number is 10

      45 Mins

      Why are Agile teams supposed to be small? How big are they supposed to be? Most agilists tend to agree that a team of ten people works well.

      But what is it about the number 10 that makes it the “magic” number?

      Since the start of human evolution, people formed groups to be more effective. Whether it was the hunt for a mammoth or going to war, working in teams ensured a greater chance of success.

      There have been various researches from Dunbar’s paper through the Scrum Guide to military formations about the ideal number of people in a team.

      We’ll discuss the historical, scientific and cultural reasons why 10 seems to be the magic number of forming effective teams.

      Does the number of team members really matter? Is 10 really the magic number. You will get an answer that will help you to create effective teams with the right amount of people.

    • Vivek Ganesan

      Vivek Ganesan / Rejikrishnan Rajan - Reinventing DevOps Practices for Blockchain Applications

      90 Mins

      With the arrival of distributed applications that run on Blockchain, it is essential to rethink some of the basic aspects of DevOps. Few things that we take for granted in DevOps area are either irrelevant, impossible or too costly for blockchain applications. Join us to explore the changes that the blockchain apps bring to the DevOps arena, using a hands-on demo of a sample blockchain app.

    • Arijit Sarbagna

      Arijit Sarbagna - Future of Agile: Digility 2020

      45 Mins

      Are you directly/indirectly involved with Agile software delivery? If yes, you may have already started questioning yourself “what next”? We have seen the evolution of Agile software delivery over years. Kent Beck took best practices to extreme levels way back in the nineties. We saw Agile Manifesto for Software Development coming out in 2001 and Scrum gaining popularity. And gradually organizations realizing that simple Scrum (or pure Scrum) may not work for large scale deliveries - leading to formation of multiple competing Agile Delivery Frameworks like SAFe (Scaled Agile Framework), Nexus, LeSS (Large Scale Scrum) and many others.

      But as we get uprooted by the wave of Digital Transformation - what is in store for us in the near future? Does Agile stand a chance to exist (or co-exist) as is? Or will it need to run through a sea change to survive?

      We explore the future of Agile (for software development) in this talk and see the possible change that we may expect to see in the next couple of years.

    • Rajith Raveendranath

      Rajith Raveendranath - Blazing fast Big Data processing - High performance big data processing using Micro-services & Flow Based Programming

      Rajith Raveendranath
      Rajith Raveendranath
      schedule 2 years ago
      Sold Out!
      20 Mins
      Experience Report

      An experience share about how we achieved high performance transaction pricing with elastic scaling, for a big T in the US, using Micro-services and Flow Based Programming.

      We start with the challenges faced by the telecom operator in their All IP access network which necessitates high volume, low latency transaction processing.

      We discuss the Micro-services advantage which let us build responsive, resilient and elastic services.

      We further discuss the FBP edge, which help us manage the big data effectively and also work as an event driven framework for Micro-services

      We will have a short discussion on the software stack used.

      We conclude by sharing the results and the lessons learnt

    • Jen Krieger

      Jen Krieger - So you want to be a DevOps Engineer?

      Jen Krieger
      Jen Krieger
      Chief Agile Architect
      Red Hat
      schedule 2 years ago
      Sold Out!
      45 Mins

      You’ve worked hard, you have mastered every coding language on the planet, including COBOL. You know jenkins, travis, go, containers, puppet, chef, CFengine, nagios, github, graphite, logstash, ansible, aws, gce, vagrant, cms, cvs, abc, 123, and even a little bit of TFS. Your resume is up to date, and you are ready for your next job.

      Well, slow down there… Industry trends in engineering are showing a growing desire in companies to hire people who have proven soft skills, are good at collaborating with others, and can regularly solve the most complex problem we face today: effectively talking to our fellow humans.

      Please join Jen for a self-effacing and situationally humorous conversation about the journey of becoming more comfortable with collaboration, open communication and reaching through “the wall.”

      Topics will include:

      • “Collaborate or Die” survival skills
      • The dreaded “soft skills” and how to become comfortable with them
      • What to do in common situations all engineers face
      • How to convince others that your idea is the right idea
      • How do you get the time you need to get your work done
    • Pradeep Kellangere

      Pradeep Kellangere / Zaheerabbas Contractor - Implementing Rapid and Repeatable Pipeline for an Enterprise

      45 Mins
      Case Study

      Enterprises and their individual feature teams are in a rush to build DevOps Pipelines with all the right reasons.

      While central teams are provisioning tools to be consumed at Enterprise level, individual feature teams are focusing heavily on building pipelines instead of building and enhancing business priorities.

      This results in "duplicate pipelines” solving the same problem of automation for build, test, package, infra, deploy and release using the given toolsets. - This results into duplication of efforts and redundancy.

      We intend to share our approach to build a pipeline enabled to for polygot programming languages and consumption patterns supporting various areas including.

      • A single click to deploy the complete pipeline infrastructure and app pipeline
      • Support multiple cloud deployment (AWS, Azure, etc…)
      • Adoption of open source tools
      • Clustered or non-clustered infrastructure deployments

      We will also emphasize on the implementation experience of the advanced Engineering practices in the area of immutable infrastructure, Chaos Engineering, blue-green/canary deployment.