---
title: "Types of library management"
slug: "types-of-library-management"
description: "The different types of library management categories. Read here to learn more."
updated: 2024-06-03T00:30:27Z
published: 2024-06-03T00:30:27Z
canonical: "learn.allspice.io/types-of-library-management"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://learn.allspice.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Types of Library Management

### Types of Library Management

The following categories are listed least-to-most sophisticated, but most businesses pick and choose a minimal mix of all of these.

#### In-file design Libraries

Most organizations start with an in-file design library. It’s often fully integrated into the schematic, PCB, and ECAD project files. This works for most smaller organizations as the overhead of managing a few PCBs per year is enough for a single engineer.

| Pros | Cons |
| --- | --- |
| Gratis (free as in lunch) and Libre (free as in licensing) | All of the work, every time |
| Flexible | Fully manual |
| Easy for teams without purchasing/planning | Mistakes get propagated |
|  | Different PCBs have different component data |
|  | Designs diverge every PCB revision |
|  | The longer you wait to organize, the more work it is to fix your components |

#### Ad hoc library: symbol and footprint files

Separating the symbol and footprint information from the schematic and PCB files allows them to change independently of the PCB design. Without version control, centralization and a more formal process, these libraries often have the same problems as no libraries. Designers often go rogue and make their own libraries, defeating the purpose of having external library files.

![Library files containing symbols, schematic, footprint, PCB, and component metadata.](https://cdn.document360.io/3d44af5c-3f49-4ca5-b152-10836a885c13/Images/Documentation/symbols footprintsAsset 3symbol symbols.png)

#### Version controlled library files

Version controlling external library files is such an easy and productive process to adopt, that it should be one of the first operations when starting a PCBA design. The design delays and production issues with component errors is worth the ROI on starting a minimal version controlled component library.

Version control allows you to do small daily steps to incrementally improve your libraries.

Here is an example workflow where a design engineer needs a new component, like an LVDS clock driver.

![Library files containing symbols, schematic, footprint, PCB, and component metadata.](https://cdn.document360.io/3d44af5c-3f49-4ca5-b152-10836a885c13/Images/Documentation/new component requets 2.png)

##### **Version controlled library best practices**

- Separate files for component categories
  - They all have their own complexities
  - Smaller changes more often
  - Separate resistors from capacitors
  - Semiconductors by type
    - Microcontroller/microprocessor/FPGA/etc
    - RAM
    - Logic
    - Power
    - RF
  - Hardware by type
    - Connectors
    - Cables
    - Externals (i.e. SD card, battery, antenna)
    - Fasteners
  - Operations
    - Barcodes (2D, Matrix)
    - Stickers
    - Laser markings

###### Challenges of simple version controlled libraries

Component ordering attributes are often still embedded in the symbol files at this point. They have to be manually exported and then massaged into a format manufacturers can use. Even if the information is in separate “integrated library” files or database, there is often a manual and error-prone process involved.

#### CI controlled libraries

With the addition of [Continuous Improvement (CI) Action Runners](/v1/docs/welcome-to-cicd-actions), you are able to bolt-on an automated component librarian:

- Never sleeps, never sick, always sharp, never gets distracted
- Follows process exactly
- Fetches component data
  - Extended BOM + COGS
    - Single and multiple quantity scenarios
  - Availability and lead time
    - Generate fast/slow PCB assembly turnaround build plans
  - Automatic component alerts
    - Price changes
    - Lifecyle changes (End of life, NRFND)
    - Low quantity
    - Long lead-time
- Generates where-used and usage data
- Syncs with PLM and ERP systems
  - AllSpice.io → PLM/ERP
  - PLM/ERP → AllSpice.io
  - AllSpice.io ←→ PLM/ERP
- Syncs with common databases
  - Relational: SQL, MySQL, MariaDB, PostGress, SQL Lite
  - Non-relational: NoSQL, MongoDB
  - GraphDB
- Knows every programming language and framework
  - Works with existing tech stack
    - Python/Mojo/Django
    - C/Rust
    - Javascript/Ruby
    - Anything supported by Ubuntu 2024 LTS

Here are some CI workflow diagrams

![Library files containing symbols, schematic, footprint, PCB, and component metadata.](https://cdn.document360.io/3d44af5c-3f49-4ca5-b152-10836a885c13/Images/Documentation/library management with CI 2.png)

> [!NOTE]
> CI Actions
> 
> CI is easy to understand. It’s a separate server that spins up a fresh software container (like Docker) and then runs any program in any programming language that you want.
> 
> - Run Checks
> 
> - Connect to external APIs to write or fetch data
> 
> - Generates files (BOM, Drill, XY, FAB)
> - Generates documentation (compliance, utility, history)
> 
> To learn more, visit our [Actions CI/CD](/v1/docs/welcome-to-cicd-actions) page.

###