This post was written by Jovile Bartkeviciute.
Returning for the third year in a row, the Pipeline Conference is bigger than ever! Organised by Matthew Skelton, Steve Smith, Chris O’Dell, Beccy Stafford and Anthony Green, the “unconference” is buzzing with excitement this morning!
After a quick opening talk, Matthew Skelton introduced the keynote speaker Jez Humble who started the event speaking about surveys, statistics and psychometrics.
- Just data do not tell you anything – need to have quality data. To choose the correct data, you need to have a theory and a set of hypotheses.
- Westrum Typology
- Every organisation has problems – no problem is actually a problem – you have to know the problem in order to fix it. What we do not want to know is who made the mistake, you need to know why the mistake was made.
- IT performance does matter. (2015 state of DevOps report)
- Job satisfaction predicts organisation performance, predicts culture. Psychological safety is very important for an organisations performance.
- Top predictors of IT performance:
- peer-reviewed change approval process
- version control
- proactive monitoring
- high trust organisational culture
- win-win relationship between dev and ops
- People redefine the continuous integration in order to say that they are doing continuous integration.
- Some surprises: commercial configuration management tools have no correlation with IT performance.
- This year is all about security and compliance, test data, lean practices and containers.
- Even if you think it is obvious – test with data, if the results do not surprise you, you are doing it wrong.
- Survey of 2016 report (results will be released in June): https://go.devops-survey.com/survey.php?uuid=80ce6815-4598-52bc-ba50-f9ad04aadf6f
- Need to predict the future, but you can’t.
- Tips on making changes to the project when the price is fixed.
- Three types of projects:
- Fixed Price, fixed points (set menu)
- Fixed price, fixed resources (bar tab)
- Fixed price, minimum deliverable (hybrid)
- Highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Moving from feature branching strategy to a trunk based strategy and how it affects your team.
- Release 3-4 months
- 4 week iterations
- Code reviews
- Deteriorating code base
- Divided team
Mainline development Continuous Delivery
- Release 2-3 times per week
- 2 week iterations
- Pair programming
- Improving code base
- United team
Gary Frost talked about the costliest software failures in history and risk involved in software delivery, as well as some tips on how to minimize them.
- Adding Continuous Delivery would solve most of the problems with software delivery – the essential checklist:
- Source code and build
- All code in modern VCS
- Pull requests/code review
- Code quality checks
- Build on change
- Binary repositary
- Automate Testing
- Security Testing
- Software/License Testing
- Performance Testing
- Integration Testing
- Consumer Driven Cotracts Testing
- Automate Deployment
- Infrastructure as code
- One click deploy
- Environment provisionin
- Orchestration/Operating System for Datacenter
- Living Architecture
- Metadata & data flows
- Generated architecture documents
- Living / Breathing enterprise view
- Source code and build
- One of the main blockers for the continuous delivery – the way we do segreggation of duties -need to have more integrated teams.
- You should look to high performing industry leaders, find success stories, study and replicate them.
- Continuous Delivery requires complete change, which is not cheap or easy.
- FinTech companies are a true threat to the established finance companies, simply because they do not have legacy code. The established companies should implement CI if they want to survive.
- In big companies, people come and go all the time, this leaves the “hot potato” software handed out to the existing teams.
- Hot Potato Software:
- Legacy project
- Multiple responsibilities
- Part of the release cycle
- Really flawed
- This calls for a refurbishment – re-architecture, zero downtime deployment, detach from the old deployment cycle
- Lessons learnt:
- Get business on your side
- Deal with your own stuff
- Use an incremental approach
- Be proud of your work
- Test-first development is still not as widespread as it should be – you should always test first – there is no room for it later when using continuous delivery.
- With continuous delivery – there is no safety net for the developers, thus the tests need to be a lot more reliable (proper, non end to end, acceptance testing, all the integration, contract, component…)
- Feature toggles
- Pairing (dev/dev and dev/test)
- Testers should communicate with the operations engineers – bug identification gets a lot easier
- Hypothesis driven development
- Staging is a permanent feature that has some sets of checks that must be passed in order for the code to be pushed to production – it mirrors production
- “Being dumb in staging – beats being dumb in production”
- True/False benefits of staging environment:
- Low maintenance? – Requires complex, custom, domain-specific code.
- Catches broad class of configuration, integration, and data errors? – Catches arbitrary set of bugs by accident, introduces others.
- Partitions of error and testing from users and rest of business? – Partitions testing from users and rest of business.
- “Known-good state” makes it convenient gate for signoff, QA/UAT etc.? – “Known-good state” makes it convenient for signoff, QA/UAT etc.
- There are two main approaches to software development process:
- reach a known good state
- apply/replay to production
- Continuous / no staging
- release when it is releasable, not when it is complete
- defensive code
- No staging environment still has some remaining challenges: performance, SSL, DNS-dependant capabilities.
- In general, if you can release it without downtime, you do not need to stage it.
- What makes continuous delivery better?
- Hiring the best people you can find.
- Help people think about production
- Testing as an activity, not a phase
- Metrics, monitoring and alerting
- Rapid response
All in all, it was an enjoyable and interesting day, it was good to see .Net focused talks and more representation of FinTech. The keynote stood out for us in particular due to Jez Humble‘s emphasis on the statistics and mathematical analysis behind the IT performance.
Looking forward to next year!