Steve Neely is officially a software engineer at Rally. In reality, he gets to play with a broad range of technologies and systems, attend and present at conferences, and write about all the cool stuff he discovers along the way. His current focus is on continuous delivery, big data, service-oriented architectures and software craftsmanship.
Steve's background is in researching the design, construction and management of globally distributed systems. He has worked at top-ranked universities across the UK and Ireland as a researcher and teacher. Steve has produced a broad corpus of research publications and organized conferences at an international level.
When Steve is not teaching Ruby at Rally, wrangling Clojure code or pushing data around Cassandra clusters you can find him rock climbing with his team or skiing the powdered slopes of Colorado.
DevOps for startups! DevOps for new projects! DevOps for a 10-year-old code base? Um ... okay ...
If you’re getting started with a shiny new product and a new deployment pipeline, DevOps is easy (well, easy-ish.) But what if you’re not just getting started? What if you’re working on a 10-year-old code base, and want to adopt DevOps… and then continuous delivery… then continuous deployment? How will the product team and business react?
We practice continuous delivery at Rally. This means that every commit to our master code branch is thoroughly tested, and builds a deployable artifact that could safely go to production whenever we choose.
Many of our services go one step further: continuous deployment.
Continuous deployment is the next step after continuous delivery. Every commit to master that passes all our automated tests, test deploys, and monitoring will go directly to production -- with no human intervention.
One of the many fantastic things about working in Rally Engineering is that we’re given the freedom to research. Our latest expedition was a foray into the world of alternatives to the Java programming language.
We were asked a tough question by one of our customers: “is a team leader of a dev team needed?”
I say yes and no and sometimes.
In 1965, Bruce Tuckman proposed the Forming – Storming – Norming – Performing model of group development. This simple model describes the phases teams roll through from their first meeting to becoming all-stars.
Ten years is a long time for a human. In compute cycles ten years rivals the age of the universe (think dog years but way faster). Rally just turned ten and our codebase is getting a facelift.
Our existing weekly deployment process approximately looks something like this:
Rally Software engineers move towards faster builds, tests, releases and value delivered to customers by using lights that track their builds. If all tests pass, the lights go green; and if any test fails, the lights go red. By blocking the engineering team with a working agreement that says "you cannot push code when the lights are red," immediate remedial action is taken when something breaks. Using a build light system makes Rally engineers' tests blazingly fast, reliable, and trusted by the team.
How well does production survive in the face of all-out failures? Enter the Rally Chaos Raccoon. Opening up your production systems to wildlife attack demonstrates confidence in monitoring, recovery, and backup processes. It stretches your failover strategies to their limits. You may think your systems are ready for anything but when a raccoon attacks there are no rules.