Do's and don'ts for continuous delivery
•Télécharger en tant que PPTX, PDF•
3 j'aime•715 vues
Presented in Agile Tour Thailand 2014
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Do's and don'ts for continuous delivery
Similaire à Do's and don'ts for continuous delivery (20)
Dernier
Dernier (20)
Do's and don'ts for continuous delivery
- 1. Do’s and Don’ts for Continuous Delivery Michael Athiwat Wongwaisayawan ThoughtWorks San Francisco
- 3. Agenda What is Continuous Delivery ? Do’s and Don’ts Q & A
- 4. Continuous Integration (CI) Continuous integration (CI) is the practice, in software engineering, of merging all developer working copies with a shared mainline several times a day. http://www.wikiwand.com/en/Continuous_integration
- 5. Continuous Deployment Continuous deployment can be thought of as an extension of continuous integration, aiming at minimizing lead time, the time elapsed between development writing one new line of code and this new code being used by live users, in production. http://guide.agilealliance.org/guide/cd.html
- 6. Terminology Continuous Integration (CI) - ability to integrate software easily Continuous Deployment - release often, up to many times a day Continuous Delivery (CD) - ability to release on demand Wolf Schlegel
- 7. Deploy != Release Deploy is putting software on server Release is making software features available for use
- 8. Deploy != Release Deploy is engineering decision Release is marketing decision Wolf Schlegel
- 9. Show of hands Version Control System Continuous Integration Continuous Deployment Continuous Delivery
- 11. Continuous delivery is a set of principles and practices to reduce the cost, time, and risk of delivering incremental changes to users. Jez Humble, co-author Continuous Delivery book http://www.thoughtworks.com/insights/blog/case-continuous-delivery
- 12. Agile software principles Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- 13. Feedback
- 14. Feedback noun ˈfēd-ˌbak Helpful information or criticism that is given to someone to say what can be done to improve a performance, product, etc. http://www.merriam-webster.com/dictionary/feedback
- 18. Important Takeaway ! Feedback Optimize feedback loop
- 19. Feedback noun ˈfēd-ˌbak An annoying and unwanted sound caused by signals being returned to an electronic sound system http://www.merriam-webster.com/dictionary/feedback
- 20. How does CD look like ?
- 21. How does CD look like ?
- 22. Do’s and Don’ts
- 23. Don’t.. manually deploy your system
- 24. Do.. automate your deployment process
- 25. Do.. use precisely the same mechanism to deploy to every environment (development, QA, production environments, etc )
- 26. Don’t.. manually provision your environments
- 27. Do.. automate your environment provisioning process
- 28. Do.. use precisely the same mechanism to provision every environment (development, QA, production environments, etc )
- 29. Don’t.. monkey patch (ad hoc modify) your servers
- 30. Do.. stop the line if anything fails
- 31. Do.. make your deploy process repeatable, reliable and up-to-date
- 32. Do.. check in everything in version control system
- 33. Do.. smoke test your deployment
- 34. Don’t.. implement CD as one-time project
- 35. Do.. roll out CD incrementally and continuously
- 37. DevOps DevOps (a portmanteau of "development" and "operations") is a software development method that stresses communication, collaboration and integration between software developers and Information Technology(IT) professionals. http://www.wikiwand.com/en/DevOps
- 39. DevOps Devops means giving a s*** about your job enough to want to learn all the parts and not just your little world. Developers need to understand infrastructure. Operations people need to understand code. People need to f***ing work with each other and not just occupy space next to each other. http://blog.lusis.org/blog/2013/06/04/devops-the-title-match/
- 41. Conway’s law Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations Melvin Conway, 1968 http://www.wikiwand.com/en/Conway%27s_law
- 43. Do.. break walls or build bridges
- 44. Don’t.. choose tools or processes because everyone is using them
- 45. Do.. understand why you want to change
- 46. Do.. understand why you want to change
- 47. Don’t.. create long lived branches
- 48. Do.. trunk based development
- 50. Do.. understand your team capability
- 51. Questions ?
- 52. Feedback please :) mw@thoughtworks.com @athiwat https://www.linkedin.com/in/athiwat
Notes de l'éditeur
- IT Consultants, we build custom software. We like to solve difficult business and technical problems as well as making the world a better place. We have office in all continents around the world. We have a number of ppl here from SG and we are hiring.
- Aim is to avoid big integration or “merge hell” Tools like CruiseControl, Hudson, Jenkins, TeamCity, Go. These days, you can run unit test, int test to get better feedback from your codes
- Check in -> Automate all the way to production
- CD = Next step of Cont Deployment. Would it be better to do Cont Deployment ? This is what people misunderstood the most in Cont Deployment, Deploy = Release
- in CD, Deploy != Release
- often times these decisions cannot be made independently. Marketing cannot release features because they have to wait for deployment windows that only open 2 times a year. or Marketing cannot release feature A just because Engineering team already start working on feature B. They don’t want to have customers see the incomplete of feature B, so they have to wait until feature B is done and release them together.
- Before talking about Benefit Show of hands of roles too
- Benefit Build Measure Learn loop. Put Idea out there, collect data and analyse them, use what they learnt to improve the product CD helps speeding up process. Imagine, marketing can release feature they want at the right time.
- It’s not just engineering practices that benefits engineers. it’s principles that benefit every stakeholders including customers That’s how we get the name. Someone said, CI and CD, is not luxury, it’s a MUST.
- TED talk, - if you want changes in behavior, you just give them feedback. And if you continue to provide feedback and make it continuous loop or cycle, you will tend to do better path than last time.
- One example, This is a Radar Speed Sign. It tells drivers how fast their cars are. It’s not a new data. Everyone drivers can know their speed. This sign did not tell drivers to drive slower, it just made drivers do the right thing.
- in SW dev, especially in Agile world, we use feedback all the time.
- This is the core of Agile, Lean Start up and CD
- Noise, Pick and choose your feedback wisely. Code Coverage.
- Typical Agile team Transform from waterfall by combining analysis, develop and test process in short iteration. Having working SW every 2 weeks But Marketing still cannot get it until 2 months later due to problem in deployment process ? or just need to wait for yearly release. Why Developers need to stay late on Friday night , weekends or even holiday to support deployment problems, and usually there are. Those painful in-efficient process is called the last mile.
- CD is just incorporating the last mile into the iteration. Deployment is not an event.
- DOs is not a silver bullet. You can achieve CD even with DON’Ts but it will go much easier with DOs.
- Human Error ! Human has emotion, can get tired, not good to do tedious/repeated jobs.
- Computer is good for tedious work Use human for tasks that need brain
- Eliminate the different between environments. Or eliminate an excuse "it works on my machine"!! With this, you can even test your deployment mechanism. If deployment is non trivial job, you don’t want to do it once a year would it be better to practise more and more and get confident with it. At the end, deployment is no longer an “event” No staying late, no long weekend.
- Same idea as deployment. Human is not good at tedious job.
- Eliminate the different There are tools that you can easily do it. Puppet, chef,
- Used to work on a project where everyday I got a new machine formatted. Point it out because most ppl get the deploy but not build.
- Sometimes you forget to change some config or scripts, You have a tendency to manually fix it for one time. You might even have to change in every machine. Then you are in situation where it’s called Snowflake servers where all machine are different just like snowflake
- Roll back not roll forward
- Build Phoenix Servers Drop and reprovision
- Keep history, tracable. Except username and password that you should not check in
- run web service look for files
- Ironic to improve your iterative development in waterfall fashion CD is on going process. Your need might changes or your might not know when you will need it.
- Cd is on going process. Collect data, find out what you need. Pick low hanging fruits. Gain benefit early. Then the next step will be easier. You will get benefit along the way
- DevOps is not a real role. There’s no such thing as DevOps position. Solving SILO problem by creating another SILO For those you don't know Dev ops
- DevOps is a method
- Temporary role. Doesn’t need to be one person, can be Dev working with Ops. Usually trying to make build and deploy process faster. Person who jump into this temp role will have mindset all aspects in development, operation and testing.
- It’s a CULTURAL changes and you cannot HIRE CULTURE.
- It’s a CULTURAL changes and you cannot HIRE CULTURE.
- In this context, If DEV and Ops never talk to each other, I bet the deployment of software will not be easy. DevOps = the way to break conways law Also apply to programming Pete’s example. Retry 20 times CMM, call SOAP then REST.
- With Conway’s law in mind, we should not build walls (making silos) but rather break them or build bridges
- If you look at it, it’s a way of optimize feedback loop.
- It works in Google and FB might not work on you
- collect data, set criteria of success, know when to stop
- collect data, set criteria of success, know when to stop
- slow feedback. making too many pipelines Only ok if it’s short lived.
- get feedback fast easy on CI
- like FB code is deployed but turned off.
- like FB code is deployed but turned off.