This article describes practices relating to internal cloud development projects at the University of St. Thomas and is primarily intended for staff and student employees. It is not related to coursework or external business environments. With the rise of vibe-coding and AI-assisted development, it may be helpful to understand how the university approaches development projects.
When developing workloads on AWS, the University of St. Thomas follows a DevOps/CI-CD approach encompassing planning, design, implementation, automated testing, and deployment placing these responsibilities in the hands of the developer.
A workload is anything (scripts, pipelines, functions, applications) that is deployed to, and executes in the AWS cloud environment.
DevOps is a culture and practice that unifies planning, development, testing, and deployment into a continuous, collaborative loop.
DevOps Covers:
- Planning: Agile boards, backlog grooming, requirements gathering (Jira, GitHub Issues)
- Design + Implementation: version-controlled development (Git) and Continuous Integration (CI) through the practice of GitOps
- Testing: automated testing integrated into the workflow with pipeline gates
- Deployment: automated, repeatable deployment strategies through Continuous Delivery / Deployment (CD)
- Monitoring + Feedback: loops back into planning
Instead of Developers performing phases 1–3 and Operations or SysAdmins managing phases 4–5, workloads in the cloud, backed by Infrastructure as Code (IaC), merge the two practices into DevOps.
CI/CD (Continuous Integration / Continuous Delivery or Deployment)
CI/CD is the technical implementation of DevOps — the pipeline that automates build, test, and deploy stages.
Think of CI/CD as an assembly line for software. Every time a developer saves and submits their code change, the pipeline automatically:
- Builds the application by packaging the code
- Tests the application by running automated checks to catch bugs before anyone sees them
- Delivers or Deploys the application by pushing the working code to a testing, staging, or production environment
This means bugs are caught early, releases are predictable, and no single person has to manually test, build, upload, and deploy changes.
CI vs. CD: What's the difference?
| Term |
What it means |
Simple analogy |
| CI: Continuous Integration |
Developers frequently merge code into a shared branch; each merge triggers an automated build and test |
Everyone turns in their piece of the puzzle frequently so problems are spotted early |
| CD: Continuous Delivery |
Code that passes testing is automatically prepared and ready to release. A human approves the final push |
The package is packed and on the truck; a manager signs off before it ships |
| CD: Continuous Deployment |
Goes one step further by deploying to production automatically, no human approval needed |
The package ships the moment it's ready |
Continuous Delivery vs Continous Deployment is a choice teams must make on each project, and sometimes with each component of the project. In small teams when an individual developer is responsible for the code in a repository, there is little chance of conflict, and tests and checks are fully automated, then Continous Deployment may be used.
If the repository is a large, shared repository with complex branching, multiple features being developed at a time, then a Pull Request process is typically introduced providing a formal review and sign off. In these cases, Continuous Delivery is used.
Whether using Continuous Delivery or Continous Deployment, all deployment processes should be automated, and code and infrastructure should be reviewed periodically by other team members. This ensures best practices are used, knowledge is shared, and applications mature within a structured environment.
Security in DevOps: Who's responsibility?
A common question is who is responsible for security tasks like IAM policies, execution roles, and bucket permissions? The short answer: the developer.
In a DevOps model, security is not a separate team's job that happens at the end. It is a standard part of building and deploying software.
This includes (but is not limited to):
- IAM policies for service and execution roles used by Lambda functions, Step functions, and pipelines
- S3 bucket policies to block unintended public access and provide access to approved principles
- Least privilege that grant only the permissions a service actually needs
- Encryption at rest configuration in IaC templates for any data storage
- Accidental data loss prevention configuration in IaC templates to ensure critical data is marked as
retained
- Secure access methods by ensuring secure transport is enabled in all communications
- No hard-coded secrets by storing all secrets in SSM Parameter Store or Secrets Manager
- Package/library updates and audits that eliminate vulnerable versions of third-party packages and remediate automated security scanning findings
These are not optional extras. Instead, they are part of the implementation phase, written and owned by the developer building the feature or pipeline. They should be reviewed by a Security Analyst, Cloud Architect, or Cloud Engineer.
DevOps vs. DevSecOps — Where is the line?
| Activity |
DevOps |
DevSecOps |
| Writing IAM policies for Lambda/pipelines |
✅ Normal DevOps task |
✅ Also DevSecOps when following least-privilege |
| S3 bucket policies / blocking public access |
✅ Normal DevOps task |
✅ DevSecOps when enforced via policy-as-code |
| Secrets management (no hardcoded keys) |
✅ Normal DevOps task |
✅ Core DevSecOps practice |
| Automated security scanning in the pipeline |
➡️ Starts crossing the line |
✅ Core DevSecOps practice |
| Compliance gates before deployment |
❌ Not typical DevOps |
✅ DevSecOps |
Any findings from a security audit (whether automated such as Amazon Inspector or through a manual review) is the responsibility of the developer to remediate when it occurs at the application code or IaC level (deploying encrypted resources or updating NPM packages vs. turning on AWS account features such as CloudTrail logs and scanning).
DevSecOps is not a different workflow. Instead, it is DevOps where security is automated and enforced at every pipeline stage (scanning, compliance checks, secrets detection). For most teams, good DevOps habits (least-privilege IAM, proper bucket policies, no hardcoded credentials) cover the basics without needing a formal DevSecOps program.
Rule of Thumb
- If security is a habit baked into how you build, it's DevOps done right.
- If security is an automated, enforced gate in the pipeline, that's DevSecOps.
Follow St. Thomas Guidelines for Cloud Development
All workloads in the AWS cloud environment must meet operational standards and guidelines set by the ITS Enterprise Application and Cloud Development team.
Refer to the Cloud Application Development Using SAM (Serverless Application Model) and Cloud Development and Infrastructure sections on the Developer and Cloud Tools service area to review the standards, documentation, and tools and regularly meet with the team to review your workloads.
Summary
DevOps is a culture and practice that unifies planning, development, testing, and deployment into a continuous, collaborative loop. Developers are involved in the entire life cycle of what they are developing. This allows for greater understanding, efficiency, and harnessing the benefits of operating in the cloud.
Learn More
Check out the related Knowledge Base articles to learn more about the benefits of using opinionated platforms and the DevOps and AI-assisted Engineering approach.