Main focus: Continuous Delivery
Twitter handle: @leenasn
Topics: continuous deployment, test driven development, agile software development, devops, ruby on rails, continuous integration, ruby, continuous delivery
CTO/Co-founder @ Good Karma, Bangalore.
A pragmatic & passionate programmer, lean thinker, eXtreme Programming evangelist, hooked into Continuous Delivery and a mother of two lovely angels.
Examples of previous talks / appearances:
Modifying the schema of a production database is hard. If something goes wrong, the impact on both customers and the team can be enormous. And it can be hard or even impossible to rollback a database schema change if things go wrong. And the same is true for any architectural change for a production application.
The Branch by Abstraction and Strangler Pattern makes significant application changes easier. Are there any similar patterns we can use to make production database changes less risky?
Indeed, there are. The Expand/Collapse pattern is a blueprint for making the database migration. It makes the remodelling both reversible and safe. By expanding the application to accommodate both the old and the new schemas in parallel, we can give ourselves time to:
Migrate any downstream dependencies on the old database schema
Gain confidence that the migration is safe
We contract the application to the new version, once we’ve satisfied that the old schema is no longer needed.
The pattern helps to make significant, but necessary refactorings to your data model in a continuous delivery way. Most importantly, without threatening the robustness of your production applications.
While working with our product, I’ve successfully applied this pattern to make major changes to the core of the application, all while serving customers in production. I’ve learned some important lessons about how to best implement the Expand/Contract pattern.
In this session, I’ll share my experiences on how to avoid pitfalls and succeed at these kinds of major data remodelling with hardly any downtime.This talk is in: English
Feature Toggle is one of the key practices for Continuous Delivery, but not enough has spoken about the same. This session is to give an intro about Feature Toggle and explain the advantages it has over Feature branching and share my experience while using it for the last few years.
Slides can be found here:
How do you know which debt requires attention? The focus of continuous delivery is smaller changes in a sustainable and faster manner. And anything that is slowing down this flow can be considered to be harmful and needs fix.This talk is about bringing in the segregation to identify the debt and the tactics of paying off technical debt in a matured, sustainable manner. Yes, it can be paid off provided enough focus is given to it.This talk is in: English
Practicing Katas are a great way to keep learning and this workshop focuses on learning newer ways for Test Driven Development [TDD] and Object Oriented Programming [OOP]. Lets learn better OOP [Object Oriented Programming] design through TDD[ Test Driven Development] with the Gilded Rose Kata.This talk is in: English
One common problem any delivery team struggles is to have a common understanding of "why" a product or feature is being built. The documents such as Project Charter, vision document etc. tries to solve this problem, but it’s common to see such documents exist in the repository, hardly known or read by anyone in the team. And this document rarely gets updated too. Ask your team members what is the goal of the project? You may be surprised to know how many actually know about it.
The so called "vision" or "goal" usually rests within Product Manager/Owner or any other stakeholder. There is no forum to converse about these goals or ideas as a team. The planning meetings [iteration or release planning] are supposed to take care of this, but there is no standard guidelines defined which would help to brainstorm these in a typical release/iteration planning meetings.
This is where Impact Mapping comes into the picture. It is a "Strategic planning technique", defined by Gojko Azdic, explained in the book Impact Mapping. It is a very simple technique based on the idea of "asking the right questions" which are:
Why are we building what we are building? i.e., Goal(s) of the product
Who we think are the actors who’ll get impacted?
How do we expect to change the actors’ behavior?
What are we going to do to create the impacts? i.e. the feature list / deliverables
Finally, by connecting the deliverables to impacts and goals, a map shows a chain of reasons that leads to feature suggestion.
React Native is gaining maturity as a cross-platform mobile app development solution. With a strong community around the ecosystem, mobile app development is all set to become simpler and enjoyable.
This talk is about various techniques and tools that are available for building, testing and deploying React Native apps for Android and iOS platforms.This talk is in: English