• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Continuous delivery its not about the technology, its about the people. @pipelineconf
 

Continuous delivery its not about the technology, its about the people. @pipelineconf

on

  • 4,159 views

Continuous Delivery its about the people from PiplineConf in London

Continuous Delivery its about the people from PiplineConf in London

Statistics

Views

Total Views
4,159
Views on SlideShare
3,966
Embed Views
193

Actions

Likes
19
Downloads
55
Comments
1

4 Embeds 193

http://www.scoop.it 96
https://twitter.com 57
http://blog.sahsu.mobi 38
https://www.linkedin.com 2

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

11 of 1 previous next

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Continuous delivery its not about the technology, its about the people. @pipelineconf Continuous delivery its not about the technology, its about the people. @pipelineconf Presentation Transcript

    • Continuous Delivery It’s not about the technology it’s about the people.
    • Tomas Riha Architect @ VGT/WirelessCar Passionate about creativity, change and improvement Horrible at following instructions and performing repetitive tasks MAJOR Project Liability mail: triha74@gmail.com twitter: @TomasRihaSE blog: continuous-delivery-and-more.blogspot.com
    • Three Years ago New Telematics Delivery Platform Multiple Stakeholders Continuous Regression Testing How hard can it be?
    • Regression Test Unit Testing Component Testing System Testing Rollback/Compatibility Testing Failover Testing Performance Testing
    • At first it was super easy! Small team of just product owner architect and scrum master. Huge productivity, natural test driven development. Fast return on investment All by the book.... we were doing Continuous Delivery!
    • Then we tried to scale it... ... and we failed in every possible way. We lost our test driven development We lost the individual responsibility We more or less became a automated waterfall unable to deliver daily
    • Continuous Delivery changes our behaviour Changing the behaviour of 5 people is easy. Changing the behaviour of 50 is super hard. You have to understand the changes!
    • Lets look at the roles and how they change Developer Tester PM/Scrum Masters Product Owner Operations Organization
    • Developers Everything has to work all the time! Pre Planning Dev Sys Test Reg Test Pre Planning Dev Sys Test Reg Test In traditional scrummerfall projects system only works once every iteration. No one cares if you check something in before lunch just to “save” your work. Sprint
    • Developers Pre Planning Dev Test Automation Reg Test Thats an awful lot of testing... YES! Test driven development requires that developers work with testing. Pre Planning Reg Test Reg Test Verification Verification Test Driven Development
    • Developers Pre Planning Dev Test Automation Reg Test This creates context switching but its up to the developer to step it up! Pre Planning Reg Test Reg Test Verification Verification Regression has priority! ALWAYS!
    • Developers Developers hate branches, or so they say Hate merging because it mixes their code with others Love feature branches because they don't have to integrate their work Developers LOVE BRANCHES!! Continuous Delivery is done on the trunk.
    • Developers Developers need to take more responsibility for Regression test Writing test code Testing the system Integrating their code In order to always have a working system Need to take more responsibility
    • Developers So it’s just up to the developers to shape up? The Continuous Delivery process needs to provide visibility and traceability to provide means to take responsibility. Developers need to be coached to increase responsibility and to mitigate fear.
    • Testers When we scaled up we added testers Developers were happy because they could go back to handing over code for testing. Adding testers we lost all test driven development!!!
    • Testers Agreement is key Finding bugs is not the goal of testing. Ensure we build the right application. Testing has to be done on a black box. Never verify on system files, databases or code. Verify on interfaces. Build quality in. Tests as Code
    • Testers Pre Planning Dev Sys Test Reg Test Pre Planning Dev Sys Test Reg Test Sprint A tester is a tester is a tester Manual System & Regression Testing is a reactive repetitive task.
    • Testers Pre Planning Dev Test Automation Reg Test TDD is not testing its requirement verification. Not all testers are suited to do requirement verification! Pre Planning Reg Test Reg Test Verification Verification Test Drive Development is proactive!
    • Testers Pre Planning Dev Test Automation Reg Test Not all testers have skills to do automation as its a technical task! Pre Planning Reg Test Reg Test Verification Verification Test Automation is a technical task!
    • Testers Exploratory Testing Requirement Verification ensures we deliver what we promise Exploratory Testing ensures that we improve our application Exploratory testing done without the requirements Never hide manual regression testing behind Exploratory Testing
    • Testers Changed how we look on Tester Profession Requirement Verification Specification usually done by BAs/Testers/Architects Verification Specification Automation usually done by Developers Regression Suite Management usually done by Testers
    • Testers Our most sought after profile Testers with strong technical skills Developers with strong testing skills Be either and earn $$$$
    • Testers Managing the change to the tester profession. Developers have an expanded role Testers have a changed role which is much harder to manage Testers must let developers test The Team creates the Tests as Code with the knowledge and experience of the Tester and the Developer.
    • Project Management Pre Planning Dev Sys Test Reg Test Pre Planning Dev Sys Test Reg Test Sprint Scrum really doesn't fit all that well Scrum builds up to a end of sprint release, but why not release daily?
    • Project Management Kanban inspired feature development better fit Building and releasing one feature “at the time” is a much better fit. Feature cycle Pre Planning Dev Test Automation Pre Planning Verification Verification Pre Planning Dev Test Automation Pre Planning Verification Verification Feature cycle
    • Project Management What is included in the release??? Continuous Delivery process needs to provide reporting and release notes. Visibility of feature completion is extremely important. Feature cycle Pre Planning Dev Test Automation Pre Planning Verification Verification Pre Planning Dev Test Automation Pre Planning Verification Verification Feature cycle
    • Product Owners Want just what they ask for nothing else. Are extremly scared for half finished features. Shared bug fixes are ok but not shared features. Product Owners love branches
    • Operations In the long run DevOps is a must! Infrastructure needs to be versioned, dependency managed and deployed with application using same mechanisms in all environments infrastructure & configuration as code Operations & Infrastructure architecture needs to be part of development
    • Road to DevOps & Infrastructure as Code Lot of parallels with road to TDD and Test Automation Dont hide configuration in code Dont hide test verification in code We can just use do it manually in the console We can just use verify it manually in the gui Developers shouldn't touch runtime environments Developers shouldn't test
    • Road to DevOps & Infrastructure as Code Lot of parallels with road to TDD and Test Automation Most of all traditional old school Testers and Operations Specialists don't have the skill set to automate as code and are used to doing manual tasks. Automation creates the same fear of in both and both have traditionally a very low confidence in developers.
    • Road to DevOps & Infrastructure as Code Lot of parallels with road to TDD and Test Automation Tests as Code needs Architecture, a dependency managed and verified lifecycle. Infrastructure as Code needs Architecture and verified lifecycle Infrastructure and Test Code needs to become first class citizens and not treated as one time scripts
    • Road to DevOps & Infrastructure as Code Managing the change to the Operation Specialist professions. Developers have to be allowed into production Manage the responsibility level of the developers and gain confidence from the Operations Specialists Operations Specialists need to understand that servers are not pets but cattle The team creates the Infrastructure as Code with the knowledge and experience of the Operations Specialist and the Developer
    • DevOps & Infrastructure as Code Next hot profiles for us Operations Specialists with strong development skills Developers with strong infrastructure skills Be either and earn $$$$
    • Cross functional consensus If the individuals don't reach a consensus on how to work with Continuous Delivery through the entire process your fancy implementation becomes the worlds most expensive CI system
    • Organisation Buy in from Organization is a must Continuous Delivery affects entire organization. Continuous Delivery CHANGES the organization and the individuals within it. But don't forget a grassroot Continuous Delivery initiative can change your organization!
    • Thats it! Feedback & Any questions you forgot to ask? http://continuous-delivery-and-more.blogspot.se @TomasRihaSE or at the Pub!