An overview of the SDLC, ALM, and CICD

SDLC.md

SLDC, ALM, and CICD

RELATED: Git Branching Strategies, Versioning, Artifacting

These processes comprise the bulk of the technical footprint necessary for developing and releasing software products.

Important

Like Git, there are too few who understand this material -- especially in startups.
While this material may not initially be as appealing to non-technical leadership as shipping a feature, it becomes imperative with the first major outage, failed InfoSec audit, or data breech.

SDLC - The Software Delivery Lifecycle includes all phases of software development from initial planning to the eventual termination of the product.
ALM - Application Lifecycle Management is the higher-level management for the product, including: market analysis, governance, requirements gathering, architecture, systems integration, and release management.
CI/CD - Continuous Integration and Continuous Delivery is an inexact term that generally represents the processes and tooling responsible for testing, building, delivering, and releasing software products.
See below for details on why context is necessary when using this term.

SDLC & ALM

It's unnecessary to redefine these concepts, but mind the following:

• The hardest thing about technology is the human element.
• The potential of the product is capped by the hiring potential of an organization.
• Size the vision against the organization.
  • Slight deficiencies may be made up with aggressive hiring strategy.
• Do NPS, eNPS, and 360 Reviews. Tend your Glassdoors reviews.

The only technical note I will raise here, is to evaluate early your Domain, DNS, and URL strategies. See Domain Names, DNS & URLS for DevOps and Friends for more on this.

CICD

Before getting into it, note the following antipatterns:

• Pipelines like: [commit]>[build]>[production] -- somehow popular with some K8s shops...
• Hosting multiple workload envs in a single PaaS (ie: AWS) account -or- single K8s cluster.
  • Every aspect of the SDLC which may affect production MUST have "TEST" environments.
    💀 Everyone knows who's responsible for not having executed reasonable effort, due diligence, and due care during an RCA.
• Manual effort in testing strategies.

While "CICD" may be suitable for embedded, or otherwise trivial scenarios, for many this is an outmoded acronym. More often it should be thought of as CICDCICD: Continuous Integration (of code), Continuous Delivery (of assets), Continuous Integration (of systems/components), Continuous Deployment (of assets).

The following diagram depicts the typical "build-once, deploy many"/"potentially-releasable asset" strategy that modern shops have enjoyed for over a decade. Web Dev Cody does a fantastic job describing it in his YouTube video: What does larger scale software development look like, if you want a step-by-step walkthrough.

Note

This diagram may be labeled "Enterprise", but this structure is found at many startups as this is simply industry standard, known-good practice, at this point.
💡 Hosted workload envs REDUCE TCO, improve NPS and eNPS.
💡 Pre-prod envs DO NOT cost as nearly much as the PROD env, as they generally run at reduced scale and with near-zero load.
💡 Ephemeral pre-prod envs don't have any OPEX when they're turned down. ;)
🗒️ Note that the pre-prod envs depicted here DO NOT use the marketing domain.

CICDCICD

This acronym breaks down roughly as:

• Continuous Integration of Code
  • Mitigate merge hell with a suitable branching strategy.
  • Ideally pre-commit hooks execute an amount of validation on the developers local prior to pushing to the remote. The size and complexity of this work can range from basic linting and SAST, to building assets and launching an ephemeral env for contract and user-journey tests, or even DAST.
  • Upon successful PR (which would have an amount of validation prior to allowing merging), the code would then be integrated with the remote codebase.
• Continuous Delivery of Assets
  • Successful merges (from PRs) result in a build.
  • The output of the build should have an amount of automated QA.
  • Regardless of QA results, the asset would be delivered with: QA Results; Attestation; SBOM; Release notes; and checksum, to Github Releases, jFrog, Nexus, etc.
  • Additional automation, such as deployment to DEV env, may be triggered depending on the QA results, and the Quality Gate configuration.
  • Assets that failed QA may still be useful in diagnosing the failures, which is why they're preserved.
    💡 These assets make fine targets for garbage collectors.
• Continuous Integration of Systems/Components
  • This is similar to integration testing in an ephemeral environment, but with hosted workload environments, such as DEV, QA, STAG, PROD. This is a key aspect of the product promotion strategy, and is a major contributor to developing qualification for deployment to production.
• Continuous Deployment of Assets
  • Cost-effective SDLCs prioritize build-once strategies which result in an asset being built once and deployed many times -- as hinted at. By transiting a well-designed suite of hosted-workload environments, by the time a product is DEPLOYED TO PRODUCTION, it has achieved a level of confidence with its stakeholders that will allow them to sleep at night (QoL). The absolute, bare-minimum suite for an Enterprise would be: DEV, QA, STAG, PROD -- with UAT, PERF, SEC, AUDIT, COMPLIANCE, LEGAL, etc., being options for scaled SDLC structures.
    🗒️ Ideally product validation & promotion through the SDLC is automated.
    💡 SDLCs with elevated infosec requirements may have an env that is maintained by an internal/external audit partner in isolation from the product group.
    • DEV: Enable developers to rapidly deploy, test, and promote assets to QA.
    • QA: Enable QA Leads to validate applications against formalized test suites. This is critical for service platforms that are a composition of products at varying states of development.
    • STAG: Facilitates activities such as load-testing, infosec/pen testing, or operational forensics which would otherwise collide with QA activities, and which may not be fully supported by the QA environment. The STAG env must as closely replicate production as possible -- if not to true scale, than to like-architecture, in capability.
    • PROD: Production.
  • Note specifically that across multi-env SDLCs, the number of assets which are available to be deployed are reduced. DEV will have the most potentially deployable assets, QA will have fewer, and as quality gates are missed only a few will be available to be deployed to production.
    🗒️ A practical example of this in AWS hosted envs would be releasing a Docker Container from the build account to the DEV account by pushing it to that ECR endpoint, etc.
    (Each workload env MUST has a dedicated (AWS/other) account.)

Here's another diagram with additional context generally delivered during whiteboarding sessions.

Tip

Products which have sensitive proprietary information may use STUB assets (functional) in lower environments, with the protected assets being introduced only for STAG and PROD.
EG: Recommender engine, or customer targeting/decision making algos; lottery system randomization or encryption libraries; etc. Note that these STUB products would be simplified, but functional versions of the real ones.

Caution

Recent attention has been given to Docker image "shadow builds" which are only identifiable by noticing digest changes. These are often patch builds, but could be anything. Regardless, these lead to untested assets in most environments as validating the digest is unusual, but now mandatory.
See Versioning for details on how best to approach scheduled patch builds.