Your SlideShare is downloading. ×

30 days or less: New Features to Production

623

Published on

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

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

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

  • Be the first to like this

No Downloads
Views
Total Views
623
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Karthik Gaekwad@iteration1
  • 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.  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.  Few features at a time. Design->Implement->Test->Deploy
  • 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.  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.  Create the Cloudlet Model  Describes the end to end system.  Dev and Ops communicate effectively. Core belief:  Model Driven Automation.
  • 8.  Design the feature Core belief:  Build platforms, not applications Reuse existing platforms
  • 9.  Proactive stance with @wickett on the team @wickett- CISSP, GWAPT
  • 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.  Not Ctrl+S Source Control!  We use Perforce/TFS “If it’s not in source control, it won’t be deployed”
  • 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.  PIE Time- Our homegrown DevOps tool. Create the PIE recipe (System Model Files) Deploy to the environment of our choice- typically Dev/Test
  • 14. People “get it” when they see it. End of Iteration demos Demos to the end users Iterate based on feedback
  • 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.  Cultivate an open culture Easier to track what happened with frequent releases Internal Users can read at their own convenience
  • 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.  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.  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.  Questions? Find me here or on twitter @iteration1

×