DevOps is usually defined as a software development methodology that combines software development with IT operations. The goal is to shorten systems’ development life cycle while delivering features, fixes and updates frequently in close alignment with business objectives.
Putting DevOps into practice is an ongoing experiment for many organizations. Developers often struggle with continuous integration (CI) or continuous delivery (CD) performance, testing delays and other bottlenecks. In fact, one survey reported that only 34% of projects finish on time and only 42% come in on budget. Security and development teams must collaborate to keep up with the rapid development life cycle without sacrificing security with every update.
Enterprise software-as-a-service (SaaS) apps are not distributed like traditional software; they are continuously running services. So CD is all about updating the service with a set of changes. In public clouds like AWS and Heroku, this is done through pipeline stages (e.g., dev, test, staging and production). In platforms like Salesforce, stages become sandbox environments, ephemeral scratch orgs and production instances.
How can development teams shorten the development life cycle without sacrificing the integrity of the features and updates? In this eWEEK Data Points article, David Brooks, vice president of product for Copado, shares with readers the key steps to achieving predictable, reliable release management.
Data Point No. 1: Advanced planning ensures all boxes are checked.
Agile planning is now de rigueur for enterprise development. It is best used if the product itself will most benefit from flexibility—if regular face-to-face interactions and collaborations are needed between team members, and when the end product requires regular updating, monitoring and continuous delivery to the client throughout the life cycle.
For CD, ensure your user stories are sized correctly and that each story rolls up to an Epic that represents a stand-alone feature. This enables your team to release bite-sized pieces of functionality that are consumable by users and traceable back to your release plan. Also, define acceptance criteria for use in the verify stage so you know when something is done-done.
Data Point No. 2: Manage the source code, especially when working in a shared environment.
There are a few practices of app creation that impact CD. First, source code is not the only element of an enterprise solution. Schema, user interface, access control rights and static resources like icons and images are all part of the creation process and should be managed just as diligently as source code. They should all be checked in to a version control system (VCS) as a single source of truth.
Second, ensure that developers are making changes in a segregated environment. In some low-code platforms like Salesforce.com, this becomes a challenge, but even in a database, multiple database administrations (DBAs) can step on each other’s changes when working in a shared environment.
Data Point No. 3: Automated quality processes are difficult to implement ...
... but essential. Selenium is a great tool for testing functionality and should be part of your practice. However, there are several verifications that should be made before you get to functional testing. Static code analysis tools like PMD are essential to ensure your development team is coding against a single style.
Define a team style and enforce its use. Unit test coverage is also essential—incorporate them with a coverage of at least 75%. Finally, after these automated tests pass, implement a manual peer review. Old hands are able to spot opportunities for performance improvement where automated tools may not.
Data Point No. 4: Changes should be released in a defined pipeline with strict quality gates.
Packaging for CD is about capturing changes that can be incrementally released into the next stage or environment. Development teams should dedicate a branch for each stage and bundle incremental changes into a promotional branch to leverage the merge conflict detection in your VCS.
Changes should be released in a defined pipeline with strict quality gates that ensure the verification steps and enforce the order of release stages. Developers should not be able to bypass key stages throughout the development cycle—for example, moving from development to production.
Focus on making smaller changes, which result in reliable, predictable releases. Finally, be sure to automate promotions. This enables your team to validate the promotion scripts in integration, test and staging before releasing to production, which decreases the likelihood of an unhappy surprise.
Data Point No. 5: Automate configuration, especially for end-user access rights.
Make testing for proper configuration part of your verification process. Platforms like Salesforce have powerful profiles and permission sets that enable user access to only the right information. Improper configuration can expose personally identifiable information (PII), credit card numbers or medical health data.
Data Point No. 6: Monitor for more than just service availability and performance.
Most SaaS companies monitor service availability and performance. But excellent companies also monitor data access to detect improper configuration changes and monitor end-user feature usage, which gives product managers visibility to their usage.