Skip to content

CI/CD and Developer Experience in Education

Software Engineering and Education

"Software Engineering is primarily a learning endeavour, the working code is rather a side effect." - Alberto Brandolini

The domains of software engineering and education have a lot more in common than we recognize. The trend of Agile, DevOps, and now the rise of Internal Developer Platforms all share a common theme: learning by designing for feedback loops. In software engineering, feedback loops optimize delivery speed and software quality. In education, feedback loops optimize learning.

If we apply software engineering principles to education, we can create a learning environment that is more engaging, effective and authentic. Both for students and lecturers.

Rather than trying to measure learning — much like the industry's elusive quest to measure developer productivity — we can design for it, by optimizing the conditions under which people learn best. This is where the concept of Developer Experience comes in, and why we built this platform.

Developer experience as a framework for learning

To understand how to design for learning, we can look at the concept of Developer Experience (DevEx, Noda, Storey & Zagalsky, 2023) from the software engineering world. DevEx is understood through three core dimensions:

  1. Feedback loops
  2. Cognitive load
  3. Flow state

These dimensions describe the conditions under which developers do their best work — and apply directly to learning.

Feedback loops

Fast feedback is at the heart of both good developer experience and effective learning. When the gap between action and result is short, people learn faster and correct course sooner.

The platform creates three types of feedback:

Stakeholder Feedback Technical Feedback Process Feedback
Question Am I building the right thing? Does my code actually work? Are we working effectively?
How Coaches and users evaluate working software early and often Automated builds, tests, and deployments surface defects immediately Integration frequency and collaboration patterns become visible

Every deployment becomes a learning opportunity — whether from a coach's review, a failing build, or a team's integration patterns. This is grounded in Minimum Continuous Delivery: trunk-based development, automated builds, and deployment on every push.

Cognitive load

Team Topologies (Skelton & Pais, 2019) distinguishes three types of cognitive load:

  • Intrinsic — the inherent complexity of the task (e.g., learning to write a REST API)
  • Extraneous — complexity imposed by tooling, process, or environment (e.g., figuring out how to deploy)
  • Germane — the effort of building mental models and transferring knowledge

A well-designed platform minimizes extraneous cognitive load so that students can invest their effort in intrinsic and germane learning. This is why the platform provides a "golden path" — zero-config deployment, pre-provisioned databases, ready-made dashboards — so that students focus on software engineering, not infrastructure.

In Vygotsky's terms, the golden path acts as scaffolding: it supports students at the boundary of what they can do independently (the Zone of Proximal Development). As students grow, the platform can offer more control (see Tier 2 on the roadmap).

Flow state

Flow — sustained, focused engagement — depends on fast feedback and low friction. Every interruption (broken tooling, unclear errors, manual deployment steps) breaks flow and wastes learning time.

The platform is designed to keep students in flow:

  • One action to deploy — git push to main, and the pipeline handles the rest
  • Self-service debugging — Grafana dashboards let students diagnose issues themselves, without waiting for a coach or platform admin
  • No context switching — CI runs are visible in the student's own GitHub repository, integrated with pull requests. Students don't need to leave their development environment.

The platform

Students deploy from day one with a single git push — no Kubernetes knowledge required. GitHub Actions builds a container image, Harbor stores it, and ArgoCD deploys it to the team's isolated namespace — live within minutes. Each team gets their own database, public URL, and Grafana dashboard. See the architecture page for the full technical details.

Early observations

The platform is deployed for the PRJ2 course (2nd-year software engineering), running on a Kubernetes cluster on Fontys EduCloud.

  • 15 teams (70 students) onboarded, each running a Svelte frontend, Java backend, and PostgreSQL database. Onboarding time after initial setup: under 10 minutes for the entire class.
  • Coaches have more visibility into the development process and can give timely feedback on working software, not just code. Early integration and iterative development are easier to push for when infrastructure is not a barrier.
  • Students run into discussions around integration patterns and ways of working together earlier in the project.

These are early signals — we plan to evaluate the platform's impact on learning more rigorously in future iterations.