Rapid prototyping- the lean way
Rapid prototyping- the lean way
Branching for CD? Think Again!
Developer 2.0 - Redefine the Role of Developer to achieve Success for All
Gone are the days where developer was responsible for just writing clean code. Traditional definition of developer affects the individual developers more than it affects the organization. The developer tends to concentrate on getting better at just the area of coding and ends up not learning the nuances of building a successful product.
As a Developer 2.0, the developer performs all of the following roles.
2. Devil's advocate
3. Code Reviewer
A developer can work in multiple stories but cannot do more than one of the above tasks for the same story. For example, the same person cannot be both the coder and Devil's advocate.
A team at Gainsight worked with this improved definition of developers and saw higher product velocity, better awareness about product and increased responsiveness to issues.
This session will take the audience through the improved definition of the role of developer and present some thought-provoking questions to the audience to make them realize that the traditional definition of role of developer is just not enough.
Devops implementation in an ecommerce platform
We will present our implementation experience of implementation of DevOps methodology , tools and approach towards the continuous deployment in our ecommerce platform implementation. We will talk about aspects related to how we developed the Build Pipeline, focused towards continuous delivery and deployment
Nightmare to Nightly builds...
This topic is a case study of a company where the production, testing, staging infrastructure and the branching strategy have been improved as part of agile transformation and continuous integration and delivery. This is a true engineering culture shift to a "nightmare" of production deployment to "Nightly build and deployment" culture.
This talk also covers some of the best engineering practices that the team used to achieve this goal. These practices include: Test Driven Development, Pair Programming, Whole Team, Collective Code Ownership, Small Releases, Continuous integration, Refactoring, feature toggles, etc. concepts.
Who Will Test Your Tests?
Some of us must have been on that one project, where your test suite was causing more problem than solving it. You change one thing, and hundred tests will fail. Your continuous integration build will fail randomly, but will pass if you just re-trigger it.
This eventually leads to people losing all the trust on test suite. They stop adding tests, because it’s more painful than writing production code. They start ignoring failing test, because they fail randomly and nobody knows why. Everybody knows tests are now more trouble than help.
In this talk, we will talk about some behaviors and reasons which leads to this "flaky test suite" situation. What are some development practices, which can avoid such situation. And finally we will also talk about how to fix this situation if you already in it.
8th August -
Learn Play 2 Java in TDD Style
The objective is give a hands-on experience of building end to end Play 2 - Java application using TDD approach (unit testing, functional testing) from writing routes, controllers, services dependency Injection and deployment to Heroku.
The idea is to incrementally add test cases to a sample App (routes controllers, services, dao etc) and explain the concepts of Play framework and also introduce new test tools like mockito, code coverage, FEST assertion matchers etc
For e.g. Testing controllers (introduce junit & FakeApplication concepts), difficult to test because of external dependencies in controllers like (dao, web services etc) - introduce Services using Spring DI, Mockito for unit testing, FEST and hamcrest assertions etc), How much code has been tested - introduce cacao for code coverage,and finally deploy to heroku.
At the end of the session, the participant should find it easy to understand end to end Play 2 App and its ease of writing tests.
7th August -
Common Blind Spots on the Journey to Production and Beyond
Many teams are getting on the bandwagon of CI and CD - but they tend to miss out on some of the aspects of software development. For eg:
1) What branching strategy (at the SCM-level) to use for maximum speed to deploy business features?
2) What does this choice imply for CI and CD?
3) How are database changes scripted? (Do you use rails-style migrations, dbdeploy, flywaydb, etc?)
4) Do you ensure that the forward and rollback scripts don't error out? If so, how?
5) Do we ensure that the existing data conforms to the validations/rules present in the current version of the codebase that is going to be deployed next? If so, how?
This session would give ways to foresee and mitigate issues that arise with a "blind" adherence to Continuous Delivery goals