Continuous Integration and Deployment in ECAD

Continuous Integration and Continuous Deployment have become widely adopted practices within the software world. The concept of Continuous Integration and Deployment don’t need to be limited to just software - they can be extended into the ECAD world as well. In this article we will address both concepts and how they can be leveraged in ECAD tools.

Continuous Deployment

Designers will frequently make changes to their code and check it into the server. That code will need to be compiled and generated into an executable or package for it to be evaluated by others. A build machine (or server) can take that code and generate it into a “deployable package” for everyone else to evaluate without the hassle of the team pulling the code and compiling it themselves locally. As the designers’ commits are continuous, so too are their deployments. This is the concept behind Continuous Deployment. Let us look at how it can be extended into the ECAD framework.

When a design is continuously being committed to a version control system (e.g. Subversion or Git), having a simple way to deploy a “design package” to your design team, especially those who don’t have access to an ECAD tool, goes a long way. Moreover, linking those design packages to a specific requirement, issue, or new product feature enables a high level of traceability that is usually found in email threads or expensive and complicated tracking systems. In one of my earlier articles, End-to-End Tracking of Your PCB Design, I discuss the concept of linking commits to a series of Jira tickets that track your requirements or issues within a design. The next step to that would be deploying your design packages via a build system (e.g. Bamboo or Jenkins) which then links those packages to the Jira ticket as well.

Let’s look at an example to understand how this would work. A board designed using Altium Designer may have many different data packages that go into a release but for the sake of simplicity let’s define a “design package” as:

1. Fabrication and/or assembly files (e.g. Gerbers, ODB++, IPC-2581, BOM) that will enable the printed circuit board to be manufactured and assembled
2. Mechanical model of Printed Circuit Board Assembly (PCBA)
3. Electrical and Design Rule Check Report (ERC and DRC)

Assuming that each design check-in, or commit, has been linked to a Jira issue we can see what changes have occurred on a design at a particular commit and then compare it with a previous commit within the ticket. (This comparison assumes that the user is using Altium Designer to view the binary files. For more information on commit commits please refer to How to "Git" Collaborative with Altium Designer.) What if someone from the procurement group or mechanical engineering department wants to access those packages? Do they need to set up and learn an ECAD tool just to get the information they are looking for? The truth is, they shouldn’t. Alas, comes the concept of continuous deployment. Every time the designer commits their design to the server, a new fabrication/assembly file package and mechanical model will be generated for the other team to review. This allows the procurement department to review the Bill of Materials (BOM) on every commit, and enables the mechanical engineer to take the STEP file and integrate it into their assembly every time the designer makes a change.

Continuous Integration

Let us now take the concept of Continuous Deployment in the ECAD world a step further. The same system that performs the deployment, or build, can also do sanity checking to make sure your contribution integrates easily with everyone else’s. This concept is called Continuous Integration and it aids the design team by integrating all of their pieces together without conflict. A standard practice within continuous integration is the use of testing. Just as you would test your code locally before committing your design, the build system will do the same. Every time a piece of code has been committed to the server, the build system will first test the code, build it, and then deploy it. In the ECAD world this gets a bit trickier than just a design package deployment as it requires a bit more intelligence.

The capability to “test” one’s design can be endless so for the purpose of this article I want to focus on three different examples of “tests” that one can run against their ECAD package. These tests are:

1. BOM Checking
2. Item Manager Checking
3. ERCs/DRCs

BOM Checking: A common issue that has come up within the last year or two has been component shortages. One will frequently find that a standard, widely used ceramic capacitor is out of stock with quite a long lead time. Sometimes one will plan to purchase a component only find it gone a few days, or even hours, later. Real-time availability for components has become an essential feature needed in one’s design tool. The Altium Designer ACTIVEBOM^® Manager solves this problem by providing real-time part availability and lifecycle information. Pair this up with continuous integration and you now have part availability information checked every time you commit your design to the repository. Treat this as a test, and your build will “fail” if a component is out of stock or if it is no longer recommended for new designs.

Item Manager Checking: One important aspect of designing within a team is ensuring that all your library parts are up to date and tracking within your company’s library. Item Manager in Altium Designer performs this checking for you and will let you know that your components are linked to the company library and are the latest and greatest. Pair this with continuous integration and you now get a failed “test” letting you know which library parts have gone rogue so you can chew out the designer who’s feeling like a cowboy that day.

ERCs/DRCs: Electrical and design rule checking is a must for any modern-day design. Ensuring that you are not violating any errors throughout your design lifecycle is critical. The one thing we all hate is completing a design only to find out we’ve accumulated hundreds of errors and thousands of warnings. Having your continuous integration “test” against these reports and publishing them on every commit keeps you, and the team as a whole, up to date on any design issues.

Conclusion

In this article, we reviewed the concept of Continuous Integration and Deployment in the software realm. We discovered that not only does it have benefits for the software folks but it can be extended to the ECAD world as well. Following the practice of continuous integration and deployment in the ECAD space keeps us on track and enables our ability to be more collaborative and transparent with our team.

Talk to an Altium expert today to learn more or continue reading about seamless ECAD/MCAD PCB data integration in Altium Designer^®.