30 days or less: New Features to Production

965 views

Published on

These are my slides from the ignite talk from DevOpsDays Austin 2012.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
965
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
7
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

30 days or less: New Features to Production

  1. 1. Karthik Gaekwad@iteration1
  2. 2.  Member of the Cloud Team @NI I’m the dude that plays the dude that designs and implements REST Services and Web Apps. Platform Owner- “Canopy”- User Management and licensing for NI Cloud products.
  3. 3.  Typically, NI has a yearly product releases  Waterfalley Cloud Iterations: monthly  Feature by Feature  Features ready for production deployment at the end of an iteration
  4. 4.  Few features at a time. Design->Implement->Test->Deploy
  5. 5.  We listen! Know what we are really trying to accomplish. Who is my end user?  Interact with the end customer. Do I understand the feature?
  6. 6.  Create ‘Research Item’ tasks  Don’t have enough information upfront  need to investigate an approach. Make this time bound. Goal: Know what a prototype would look like, and how it may function.
  7. 7.  Create the Cloudlet Model  Describes the end to end system.  Dev and Ops communicate effectively. Core belief:  Model Driven Automation.
  8. 8.  Design the feature Core belief:  Build platforms, not applications Reuse existing platforms
  9. 9.  Proactive stance with @wickett on the team @wickett- CISSP, GWAPT
  10. 10.  Best practice: Don’t write crappy code  Make it robust & resilient Fix bugs as soon as you can Get it reviewed Never release with known bugs.
  11. 11.  Not Ctrl+S Source Control!  We use Perforce/TFS “If it’s not in source control, it won’t be deployed”
  12. 12.  Unit Tests to test out individual methods Integration Tests to test out system Production Ready?  Load Test  Monitors that can execute custom workflow checks Worst advice ever
  13. 13.  PIE Time- Our homegrown DevOps tool. Create the PIE recipe (System Model Files) Deploy to the environment of our choice- typically Dev/Test
  14. 14. People “get it” when they see it. End of Iteration demos Demos to the end users Iterate based on feedback
  15. 15.  Push to production  Pushed by the Operation Team The act of pushing files to production SHOULD NOT be a big deal. If it is, the process has holes.
  16. 16.  Cultivate an open culture Easier to track what happened with frequent releases Internal Users can read at their own convenience
  17. 17.  Don’t freak out. Figure out what (really) broke. Figure out why it broke. Accept that it happened. Fix the code! Write a new integration tests/ monitors for this
  18. 18.  Know your end user.  The customer is your biggest ally Agile is a process.  Tweak it, to make it work for you Release Early, Release Often.  Bigger the release, more stuff that will go wrong  Harder to rollback Create integration tests that can be executed by the whole team.  Great when you are on vacation!
  19. 19.  Keep system designs simple.  Complex cloud designs are brittle and hard to scale Log like a champion!  But not sensitive data Create APIs to measure metrics.  Even more important in the cloud If you do something awesome, tell people.  Others are solving similar issues #DevOpsCulture
  20. 20.  Questions? Find me here or on twitter @iteration1

×