Paths · RCC ClusterDocs
Software development path
Use this path when your main goal is to build reproducible research software, workflow automation, containers, protected applications, Shiny interfaces, or model-backed services.
Service status: RCC Admin, RCC workers, and Slurm workflows are ready now. Project vhost hosting is not yet released; website and service classes currently prepare future requests and applications.
Use VS Code with Remote - SSH as the default editor and project interface unless your team has a reviewed alternative. Open the smallest useful repository, exclude data and generated trees from search and file watching, and submit sustained work from the integrated terminal through Slurm.
1. Build the shared foundation
| Step | Learn | Why it matters |
|---|---|---|
| Class 1 | Safe SSH and VS Code Remote SSH | Develop through an individual, verified account |
| Class 2 | Project structure, Git, and environments | Make changes reviewable and repeatable |
| Class 5 | Slurm execution patterns | Keep sustained work off login hosts |
| Class 6 | Managed Snakemake | Turn dependency graphs into bounded Slurm jobs |
| Class 7 | Planned Nextflow and nf-core | Prepare reviewed pipelines for the not-yet-released service |
| Class 4 | Immutable Apptainer images | Package reviewed runtimes reproducibly |
2. Choose the software shape
The optional account setup patterns describe reviewable shell, prompt, Conda, and bounded Shiny practices.
| Goal | Continue with |
|---|---|
| Batch analysis or dependency graph | Class 6: Snakemake |
| Reviewed Nextflow or nf-core pipeline | Class 7: Nextflow |
| Python analysis package or notebook workflow | Class 9: Python |
| R analysis package or report | Class 10: R |
| Shiny application | Class 11: Shiny |
| Future protected project website or API | Class 8: project websites — not yet released |
| Notebook or model prepared for a future service | Class 12: notebook to service |
| I/O-intensive workflow or temporary database | Class 14: efficient local I/O |
| Storage-path or cache diagnosis | Class 15: storage architecture |
3. Design for review and operation
Keep configuration separate from code. Validate inputs, bound CPU, memory, storage, request size, concurrency, and execution time. Run expensive work through Slurm and return later for results instead of keeping a web request open. Use read-only inputs and narrowly scoped write locations.
Record dependencies, image digests, migrations, tests, logs, health checks, backup expectations, and an owner. Never embed credentials, patient identifiers, internal topology, or project data in Git or container images.
4. Publish through the governed route
A local demonstration is not a production deployment. Project vhosts are not yet released. Use Class 8 to prepare the application contract and future request, but do not present it as deployed. After release, authentication, reverse proxying, TLS, logging, lifecycle management, data protection, and incident handling will remain part of the reviewed RCC service boundary.