Top 10 Signs Your Development Process Is Ready for an Upgrade

Need to deploy high-quality software faster? Think DevOps.

DevOps practices create unified, cross-functional teams in which all groups – from development to operations – work together throughout the development process, to create better software solutions in shorter intervals. Moving to DevOps requires key changes to a team’s culture, processes, and tools. Are you ready to change the way you deploy software? Here are the top 10 signs you need to upgrade your development process.

1. You rely on your developers to manually execute unit tests prior to check-in. It gives them something to do. Why spend time on a manual process when you can automate? This is a big part of DevOps – creating repeatable processes that can be automated. Through the use of modern development and version control tools, DevOps lets you easily ensure tests are running prior to committing code to shared locations.

2. You hear someone on the development team say, “It works on my machine” at least once a day. With DevOps, what developers see is what everyone sees. Using automated configuration management tools to recreate existing conditions in upstream environments, developers ensure code runs consistently on all platforms – before the build and deployment.
3. You need an archaeologist to find the last stable version of your code base. Old methods won’t keep up with today’s development pace. That means you need to move beyond manual processes and find new ones everyone can follow. It’s essential to develop a branch/merge strategy from the start so that everyone on your team is using the same source control repository. This means your team smoothly delivers high-quality software, rather than untangling a web of merge conflicts.
4. Late-night releases require endless conference calls, and a bottomless coffee supply. If your updates require hours of downtime at odd hours, it’s time to let go of manual processes in favor of those that can be automated. Even in critical situations like deployment to production, automation is a key component of DevOps. Becoming comfortable with automation, and understanding how easy it is to recover from a failed deployment, changes the way teams feel about deploying new code to production.
5. There is a delay prior to deployment because the last release caused an outage. (Hint: Operations does not forgive, and Operations does not forget.) DevOps involves Operations team members from the getgo. DevOps cross-functional teams work together to deploy software to production and have a shared understanding of time and effort that went into building the quality deliverables they deploy.
6. You take out an insurance policy on the single person responsible for “building” the app prior to deployment. No one person is on the hook for a build in DevOps processes. The build developers run on their machine is the same build that runs on the Continuous Integration server. That build and its related tests should be run as often as possible, often on check-in of code. Those build artifacts need only be constructed once, and should be deployed everywhere – not rebuilt for different environments. This should happen with a series of tools and practices working in concert – Continuous Integration, Dependency Management, Artifact Archives, and SCM tools. Spreading the build across different environments puts the responsibility, risk, and reward on the team, rather than on just one individual.
7. Your infrastructure diagrams make beautiful art on the wall – but they’ve been obsolete since go-live. Drawing out the infrastructure the old-fashioned way still works. But more and more often, teams use virtual infrastructure, both in the cloud and on premises, to host their applications. Automated Configuration Management tools manage complex virtual infrastructure. Chef, Puppet, Ansible, and Docker can be used to store infrastructure configuration information as code, that can be version controlled, and to monitor configuration changes happening on managed servers, to prevent unauthorized “shift and drift” of resource configuration.
8. When shareholders ask how long until a requested feature is in production, your blank stares and shoulder shrugs are generally met with disapproval. Another cultural aspect of DevOps is becoming a learning organization. It’s important for teams to analyze their normal delivery practices to ensure they’re functioning as efficiently as possible. This can be a great boost for team morale, and involves tracking metrics related to team performance that may not have been captured in the past – stats related to percentage of successful builds, lead time to feature deployment, and mean time to recovery after failures.
9. Generally speaking, you like to test your apps AFTER deployment. Shifting the focus on quality to shared environments beyond the developer’s workstation touches all three aspects of DevOps. Culture: Teams need to take ownership of keeping shared environments stable, and be responsible for keeping builds healthy and well-tested. Processes: Development processes, like integration tests and TDD, support this. Tools: Start using tools to manage test data, tear down and recreate local test environments, and ensure test environments are in sync with shared, upstream environments.
10. You’re not positive you know what a smoke test is, but you’re pretty sure it’s illegal in most states. Smoke tests are a common step in delivery pipelines, used in the DevOps process. Teams orchestrate the execution of several automated deployment and test tasks to create delivery pipelines. These pipelines control the build, deployment, deployment verification, and testing of shared environments, and can be used to enable Continuous Delivery scenarios. Teams that deploy often to production, but have to maintain a series of stable test environments, often use delivery pipelines to accomplish this. Smoke tests are used in delivery pipelines to validate that an application is functioning properly after deployment by exercising a subset of critical features.