Are you using release toggles to:

• decouple deployments from releases?
• allow micro-services to be deployed independently as and when they are ready?
  • even if rest of the micro-services required for the feature are not ready
• practice trunk-based development?

If yes, then how are you ensuring that when you need to turn on a release toggle in production, you are doing it in a safe manner? 

This session will explain how you can ensure that your CI/CD pipelines can validate, manage and promote the toggle state in a fully automated manner as part of the deployment process itself. If your teams are embracing zero-touch continuous deployment model, then this session is for you.

Large-scale software development generates a lot of data when teams use tools like Jira or Azure Devops. We could analyze the data with statistical tools and techniques in order to understand how to improve delivery performance. Naresh and Sriram have been attempting this at one of their clients. In this talk, they’ll share the techniques they used and the lessons they have learnt so far.

Welcome Address and Agile India Conf Overview. Here you will get al the important details you need about the conference. So don't miss it.

Welcome Address and Selenium Conf Overview. Here you will get al the important details you need about the conference. So don't miss it.

Dan Cuellar was selected to speak at Selenium Conference 2012 in London about an entirely different topic. As part of his presentation, he showed off iOS Automation using Selenium syntax to demonstrate writing platform-agnostic tests that use separate platform-specific page objects with a common interface. To his surprise, the cool test architecture would take a backseat to the spectacle of iOS tests running like WebDriver tests. Several people suggested that he give a lightning talk later in the conference to explain exactly how it worked.

On the second day of the conference, Dan stepped up on stage to give the lightning talk. Jason Huggins, co-creator of Selenium, moderated the lightning talks. Dan experienced technical difficulties getting his presentation to load, and Jason nearly had to move on to the next lightning talk. At the last moment, the screen turned on and Dan jumped into his presentation. He explained the details of his implementation and how it worked, begged for contributors, and in five minutes it was over. The crowd applauded politely, and he left the stage.

If we look at how Appium came into existence, lightning talks are a very important part of this journey. Continuing the tradition at Selenium Conf, we would like to dedicate a full session with all attendees on Lightning talk.

Submit your topic for a 3-min lightning talk. If you have slides or videos from past presentations, please include them to maximise your chance of getting selected. Selected speakers will get a free pass to the conference.

We'll go over important updates and announcements. If you've any questions about the conference, like how do I get the videos, etc. this session will help you answer all those questions. So don't miss it.

Welcome Address and Functional Conf Overview. Here you will get al the important details you need about the conference. So don't miss it.

Closing talk and thank you note!

Welcome Address and Agile India Conf Overview. Here you will get al the important details you need about the conference. So don't miss it.

Q & A with the Appium Core Committers:

• Jonathan Lipps
• Kazuakai Matsuo
• Sai Krishna
• Srinivasan Sekar
• Ayan Khan
• Christopher Hiller
• Mykola Mokhnach

Naresh Jain would moderate this panel.

Does your technical debt backlog look endless? Are you thinking about pausing feature development to resolve tech-debt? Stop. What if I told you that a good chunk of your backlog can simply wait? Tech-Debt can seem overwhelming when we look at it as a loosely organised list. This can lead to several anti-patterns in how we deal with them. Attend this session where I will be sharing strategies we have been leveraging to identify high priority tech-debt items to make sure we are able to continue feature development while improving code health.

Problem Statement: Tech-Debt often accumulates until productivity takes a serious hit and then as a knee jerk reaction we try to clean it up all at once. At this point there is just one large list of issues with a loose sense of priority. Net net it gives an impression that we have a huge backlog. This can lead to several anti-patterns.

• Chicken and Egg Problem - Too much Tech-Debt, so feature development is slow. Since feature development is slow, we cannot set aside time to fix issues.
• Fixing the wrong issues - In the larger scheme of things, it may be counter-productive to fix low priority issues just because they are easy.
• Pausing Feature Development - Approaches such as "Technical Debt Sprints" where we pause features to resolve tech-debt are not be sustainable even if they offer some short term benefits.
• Local Optima - Patchy cleanups which lead to uneven code health across the code base.
• And many more

Solution: Understand the impact of each Technical Debt at Block, Category and Item level to narrow your backlog to those issues which matter. While there are several tools that help us identify tech-debt it is up to us to map our context on those issues. Attend this talk where I will be going over how to VISUALISE, TRIAGE, PRIORITISE and STRATEGISE in order to get a realistic view on your tech-debt. Also I will be sharing my experience about how we have been leveraging time boxes and capacity constraints as a tool to make sure we are only working on the most important tech-debt issues.

Topics that will be covered:

• Tech-debt resolutions strategies - Anti-Patterns
• Tech Debt - Understanding Size vs Impact
• Tech-Debt Manifestations - Matrix view of areas of code and types of problems.
• Visualise - Triage - Prioritise - Strategise
  • Visual techniques to understand your tech-debt backlog with code analysis tools - Examples with popular tools
    • Bubble Charts - Coverage vs LOC, Maintainability vs LOC etc.
    • Git History - Multiple ways of looking at changes to a piece of code
    • Active Code Paths - Mapping usage to issues
    • Mapping Project Management Data - Bugs, Stories that touch a piece of code
  • Triaging the backlog to quickly eliminate tasks that can wait
    • Block level - Leveraging Logical Architecture
    • Category vice - Example: Front-End, Backend, API etc.
    • Item vice elimination
    • Refactor vs Rewrite
  • Prioritising tech-debt with layers of detail such as - Churn, LOC, Coverage, Bugs etc. Hotspot Identification.
  • Strategise - Approach to resolving each tech debt item based on Tech-Debt Manifestation Matrix
• Tech-Debt resolution - Hypothesis based, Data Driven approach
  • A template to capture your hypotheses, experiments and learnings
  • Visual confirmation that the issue is resolved
  • Just-Enough resolution - The uncomfortably short time-box - Imposing constraints to avoid runaway clean-ups
  • Guard rails to avoid a repeat of the same issue
• Incorporating tech-debt resolution into your Iterations, Weeks, Sprints, etc.
  • Identifying the right cadence on how often you fix debt - Hours per Day, Days per Week etc.
  • Tech-Debt back log Grooming
  • Cycling through categories of tech-debt
• Measuring Progress
  • Short-term - Measuring immediate impact on the code
  • Medium-term - Productivity improvements (Readability, Issue resolution time, etc)
  • Long-term - Team Health - Knowledge Silos, New Team Member Onboarding Time

In a complex, interdependent eco-system, where each service is evolving rapidly, we typically end up with an Integration Hell .i.e. the myriad problems that occur when API integrations break down

• Provider and consumer integrations break when their understanding of the API endpoints are out of sync
• Working integrations break when the API developer makes a change without informing the consumer
• Development and testing slow down when the consumer depends on the provider API running in a staging environment:
  • The network may be down
  • The environment hosting the API may be down
  • The staging API may crash, or may not even be started
  • Development can be delayed if the staging API is not kept up-to-date
  • API changes can come in at the last minute, resulting in breakage on the consumer side
  • The provider API may break backward compatibility, resulting in breakage on the consumer

Instead, what if we could make the dependencies between the provider and consumers explicit in the form of executable contracts. These executable contracts provide a common, clear definition of their API endpoints. They give instantaneous feedback about accidental breakage to the teams so that they can work independently. These executable contracts are:

1. Kept up-to-date and acts as a single source of truth
2. Used for service virtualisation, keeping consumers in sync with the contract
3. Run as tests against the provider API to validate it's request and response type definitions
4. Tightly integrated with CI
5. Capable of pinpointing any backwards-incompatible changes to the contract

This is Contract Driven Development, and it heralds the Death of Integration Hell.

Here's a sample contract:

This session will demonstrate all the key points of Contract Driven Development as implemented by the teams using an open-source tool called Specmatic.

In a complex, interdependent eco-system, where each service is evolving rapidly, we typically end up with an Integration Hell .i.e. the myriad problems that occur when API integrations break down

• Provider and consumer integrations break when their understanding of the API endpoints are out of sync
• Working integrations break when the API developer makes a change without informing the consumer
• Development and testing slow down when the consumer depends on the provider API running in a staging environment:
  • The network may be down
  • The environment hosting the API may be down
  • The staging API may crash, or may not even be started
  • Development can be delayed if the staging API is not kept up-to-date
  • API changes can come in at the last minute, resulting in breakage on the consumer side
  • The provider API may break backward compatibility, resulting in breakage on the consumer

Instead, what if we could make the dependencies between the provider and consumers explicit in the form of executable contracts. These executable contracts provide a common, clear definition of their API endpoints. They give instantaneous feedback about accidental breakage to the teams so that they can work independently. These executable contracts are:

1. Kept up-to-date and acts as a single source of truth
2. Used for service virtualisation, keeping consumers in sync with the contract
3. Run as tests against the provider API to validate it's request and response type definitions
4. Tightly integrated with CI
5. Capable of pinpointing any backwards-incompatible changes to the contract

This is Contract Driven Development, and it heralds the Death of Integration Hell.

Here's a sample contract:

This session will demonstrate all the key points of Contract Driven Development as implemented by the teams using an open-source tool called Specmatic.

During the Code Beam Lite conference you might have had questions that did not get answered, this is your opportunity to get them answered by our expert panel group

During the conference you might have had questions that did not get answered, this is your opportunity to get them answered by our expert panel group

Hike is a mobile-first, messaging platform that is used by 100 million users to exchange 40 billion messages/month. Hike app is available on Android, iOS and Windows phone. On the back-end, we’ve 100+ macro-services in Java, Python, Ruby, Go and Elixir. While setting up a Continuous Delivery pipeline, we ran into a series of technical challenges. However it was more important to address the organisational/behavioural challenges to ensure a sustainable culture shift in the company.

In this talk, I’ll explain how we went about:

• Setup a trunk-based development model
• Decentralised our build & test environments using Docker and Jenkins
• Segregated and containerised our macro-services
• Refactored the mobile apps to be more container friendly
• Setup a mobile device farm using STF
• Improved the quality of code-reviews using PRBuilder & PRRiskAdvisor
• Created different kinds of automated tests to align with our CI Pipeline and get rapid feedback
• Finally how we used C3 to visualise the health of our code-base

There has been a lot of concerns about the black-box nature of AI. People have been asking for a sensible AI guideline with the weight of Law behind it. In April 2019, the EU released it's Ethics guidelines for trustworthy AI. Before that during the Obama administration, the National Science and Technology Council came up with its own set of broad guidelines called "Preparing for the Future of Artificial Intelligence."

Most of these cover an impressive amount of ground in several major categories:

• Transparency: Any time an AI system makes decisions on a user's behalf, that person should be aware of it. The reasoning behind decisions should be easily explainable.
• Safety: AI systems should be designed to withstand attempted hijacking and other attacks performed by hackers.
• Fairness: Decisions made by AI systems should not be influenced by gender, race or other personal identifiers. They should be as impartial as possible and not reflect human biases.
• Environmental stewardship: Not all the stakeholders in AI development are human. The development of these platforms and the implications of their decision-making and sustainability should take into account the needs of the larger environment and other forms of life.
• And so on...

At this conference, we would like to bring our experts together to hear their views/concerns on this topic.

This talk will help you understand the vision behind ODSC Conference and how it has grown over the years.

Welcome to Agile India 2019