Send the link below via email or IMCopy
Present to your audienceStart remote presentation
- Invited audience members will follow you as you navigate and present
- People invited to a presentation do not need a Prezi account
- This link expires 10 minutes after you close the presentation
- A maximum of 30 users can follow your presentation
- Learn more about this feature in the manual
Do you really want to delete this prezi?
Neither you, nor the coeditors you shared it with will be able to recover it again.
Make your likes visible on Facebook?
Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.
Transcript of DoR
Blocks Source Control Management
[SCM] git svn cvs hg bzr Manages revisions. Manages different branches.
Tells you how the code-base evolved. Continuous Integration
[CI] Continuous Integration is a practice where members of a team integrate their work frequently - leading to multiple integrations per day.
Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. The Life of Code! Code is born. Code achieves nirvana. Dev Box Production
Servers Developer emails a patch to a Mailing List Everyone downloads the patch and applies on their local copy of code Someone builds and deploys that code to Production once in a few months Difficult to
track changes, rollback, have different versions simultaneously Code built and run on different platforms and with different versions of headers/libraries.
What ran on QA is not the same as Production. Long feedback loop -
A breaking SCM checkin is detected after a few months. Developer commits source code to an SCM All developers collborate using the SCM. Someone builds and deploys the code from the SCM to Production once in a few months Developer commits source code to an SCM Build and Deploy code on to the QA environment once in a week. Someone builds and deploys the code from the SCM to Production once in a few months CI Server generates an artifact on every checkin,
the QAs consume it once in a week.
We do not have enough people to pull it more often. Developer commits source code to an SCM That artifact is deployed on to the QA environment once in a week. The same artifact is deployed to Production once in a few months CI Server builds and gives out an artifact Who is the 'someone' who deploys artifacts on QA and Production, and how does he do it? Developer commits source code to an SCM That artifact is deployed on to the QA environment once in a week. The same artifact is deployed to Production once in a few months CI Server gives out an artifact CI Server runs the automated functional test suite At this point, we can introduce more environments between QA and Production to fine-tune release cycles. Developer commits source code to an SCM QA Production CI Server gives out an artifact CI Server runs the automated functional test suite auto
system QA CI Server gives out an artifact CI Server runs the automated functional test suite auto
system Staging Stress/Performace UAT Code is born. Dev Box Code achieves nirvana. Production
Servers SCM CI We are now at a stage where all these steps can be fully automated. Environments Dev QA Staging Perf. / Stress Production nokogiri vendorized on ubuntu,
runs on RHEL in production Dev --> Wind©ws
Production --> Linux File modes, code relying on sys-level SSH or similar utils. DB privilege level different on
QA and Production hosts. selinux configurations on ubuntu/RHEL httpd rewrites exist only on Production Dev QA Staging Perf. Production Production Perf. Staging Dev QA Incrementally progress towards a Production-like layout Mac OS X Webrick RHEL Passenger/Apache More stable Interfaces with Staging
of external services Load balanced Multi-node Production-class DB and
FS storage on SAN/NAS The Truth Ubuntu Same class - data centre / cloud Automate! Details live in emails Or on a wiki Typed commands are yanked into a 'shell script' Error handling and fine tuning of the shell script Shell script lives in bob's home folder Still outside the shell script -->
env variables, hostnames, RSA keys After considerable hacking, everything is finally in
bob's shell script Maybe we need a tool for all such things *Sigh How to bob's shell script finds its way to the SCM Manually setup environments Culture In start-ups, there are small development teams production release might mean changing dev-box DNS There are specific roles to handle specific tasks across multiple projects software middleware system engineering hardware everyone works together to make things happen In the enterprise world... this can be risky. friction! devs want to introduce change ops want to reduce risk Ops
should know Devs
should know Business Identifies a new
opportunity new feature code change Business Change Breakages Instability Downtime Outages Profit Loss Push Push Push Developers
& QAs Git CI tool Run tests OK! Run Functional Tests Make a tag OK! Tag Push the tag Pull QA selects what environment
to deploy to QA selects a tag to deploy Test Env. Pushes it onto the checks out the tag from git bundle install .bundle bundle install --deployment bundle package http://gembundler.com/ Puppet Pulls configuration
from git uses it to bootstrap
an environment New Environment which can be
added to the pipeline CI tool Deployment tool Ops harmonization! DevOps on Rails Chris Briesemeister
firstname.lastname@example.org Nikhil Mungel
@hyfather Jan 4 2011 Prevents More Culture Involving Ops early on
Involving DBAs early on
Retrospectives / RCA meetings
Plan time for NFRs and get them
signed-off from Ops.
Everyone makes money! Tools Logging - syslog-ng, gem:SysLogLogger
Config Management - Puppet/Chef
Instrumentation & Metrics - New Relic RPM Odds and Ends DB migrations are already in SCM! Rails will manage the versioning of DB schema, out of the box. rake will natually need DDL privileges to migrate the DB. gem:paraphraser can generate executable SQL from Rails migrations. Push Git CI tool QA selects what environment
to deploy to QA selects a tag to deploy Test Env. Pushes it onto the CI tool Deployment tool Pushes tag for
successful loop Code & Tests Makes an artifact for that tag .tgz .war .gem .rpm Running your own RubyGems server Have more control over what gems are being used Easy way to get on with policies or protocols that might be in place "Internal" repository, puts Ops at comfort. $gem server will start serving installed gems. Point to this new source from Gemfile Passenger gives out some very useful stats passenger-status passenger-memory-stats sample-izing yml files .yml.sample is checked in.
.yml is in .gitignore.
All configurations locally loaded via symlinks. for Rails Things that Devs help happen Things that Ops prevent from happening DBA