Component Developer Documentation
==================================

.. note::
   **Audience:** Developers working on data center components

This section provides access to detailed technical documentation for each component of
the CCAT Data Center system.

.. toctree::
   :maxdepth: 3
   :hidden:

   /ops-db/docs/index
   /data-transfer/docs/index
   /ops-db-api/docs/index
   /ops-db-ui/docs/index
   /system-integration/docs/index
   /data-center/docs/index

Overview
--------

The CCAT Data Center is built from several integrated Python packages and configuration
repositories:

**Core Components:**

* :doc:`ops-db </ops-db/docs/index>` - Database models and ORM layer for the operations database
* :doc:`data-transfer </data-transfer/docs/index>` - Automated data movement and archiving of raw data. Handles also
  staging of data to processing and upstream deletion upon successful archiving.   
* :doc:`ops-db-api </ops-db-api/docs/index>` - RESTful API for programmatic access to the operations database
* :doc:`ops-db-ui </ops-db-ui/docs/index>` - Web frontend for browsing and managing observations, monitoring the
  system and interaction with data and ops-db.
* :doc:`system-integration </system-integration/docs/index>` - Docker, Kubernetes, and deployment infrastructure
* :doc:`data-center </data-center/docs/index>` - Configuration files and reference data

Development Workflow
--------------------

1. **Setup** - Follow installation instructions in each component's documentation
2. **Local Development** - Use Docker Compose for local testing (see system-integration)
3. **Code Changes** - Work in feature branches, reference GitHub issues
4. **Testing** - Run component test suites before submitting PRs
5. **Documentation** - Update relevant docs when changing user-facing behavior
6. **Deployment** - See :doc:`../operations/datacenter_operations` for deployment procedures

Development Standards
---------------------

* **Python Style** - Follow PEP 8, use type hints where applicable
* **Documentation** - Use docstrings for all public APIs (Sphinx autodoc compatible)
* **Testing** - Maintain test coverage for new features (To best effort)
* **Version Control** - Meaningful commit messages, reference issues in commits
* **Code Review** - All changes require PR review before merging

Getting Help
------------

* Review component-specific documentation linked above
* Check :doc:`../overview/how_we_work_together` for team collaboration guidelines
* Contact the development team via established communication channels