Continuous Deployment: An Implementation Using Altium Designer

In Continuous Integration and Deployment in ECAD we discussed the concept of Continuous Deployment within a build system. In this article, we will take a deeper look at how to set up continuous delivery and deployment systems so your team and vendors can enjoy a continuous stream of updated ECAD packages for review.

Continuous Deployment/Delivery: Revisited

In Continuous Integration: An Implementation Using Altium Designer we went through the details of your PCB design integrated into a build system. This entailed:

1. Setting up Output Job files

2. Writing Altium Designer scripts in Delphi to programmatically run the Output Job files

3. Enabling your build system to run Altium Designer from the command line to generate the output files

In this article, we address the next stage: delivery and deployment. The delivery and deployment stages take your generated output files and delivers/deploys them as packages for the “end customer.” In this case our customer can be ourselves, a teammate for review, a vendor, the QA department, or an actual customer.

Continuous Deployment vs. Continuous Delivery

In the application we are about to discuss, Continuous Deployment and Continuous Delivery function almost identically to each other with the exception that delivery requires an extra step to get into the customer’s hands. According to Atlassian, Continuous Deployment takes the generated outputs from your build environment and deploys them directly to the customer. Continuous Delivery, however, requires the team to actively deliver the package to the customer. Since our customer for this application can be, essentially, anyone (including ourselves), we will be referring to Continuous Deployment as our package delivery mechanism.

Example: Team Collaboration

Recall the example we gave in Continuous Integration: An Implementation Using Altium Designer. A team is looking for the latest and greatest PDF schematics, fabrication/assembly files, and/or STEP models. Despite not having finished your design, a portion of it is “good enough” for DFM review. Perhaps placement has been locked in so that a mechanical designer can use the latest version of your STEP model. Regardless, a deliverable package needs to be generated for this group to review your design files. The Continuous Deployment system will do exactly that for every build that it has run through. For some, this example makes a lot of sense, but for others this “Agile” approach isn’t very practical. A second example can be proposed that is more practical and also can help with business-client relationships.

Example: Gun for Hire

As a PCB design firm, your customer is constantly asking for updates on their design that you are currently laying out. Zipping up weekly “updates” and emailing them to the customer becomes a nuisance and can be time consuming. If we leverage our build system, which is already engaging in Continuous Integration, we can take it a step further to deliver ready-to-go packages for our customers and/or deploy it to them automatically. This means that every commit you make to the server, your customer will get a refreshed schematic, fabrication/assembly package, and other outputs that you have set up in your Output Job file. This can be deployed to a shared network drive or a place in the cloud. This also enables your customer to view design files and packages without having ECAD software installed (i.e. automatic PDF generation via the Output Job file). For some, this may not be very attractive (as they prefer to have control over what gets released to the customer), but for others this brings a whole new meaning to the word “transparency”. If one feels uncomfortable over an automated deployment to customers, they can first generate their build, deliver it within the group for review, and then deploy that package to the customer thereafter.

Implementation

Step 1: Configure your Output Job using the output files needed for your build system.

Figure 1. Output Job configuration for generating fabrication files within build system

(Taken from the “MiniPC” Altium Designer Example)

Figure 2. Output Job configuration for generating assembly files within build system

(Taken from the “MiniPC” Altium Designer Example)

Step 2: Zip up the packages via command line. Install 7-Zip on your build machine and use the following command to zip up the package:

7z a -tzip Fabrication.zip Fabrication/
7z a -tzip Assembly.zip Assembly/

Step 3: Configure deployment system to deploy current build and verify packages have been deployed.

Figure 3. Bamboo deployment system configuration

Figure 4. Example of deployments for a Bamboo build

Figure 5. Deployment status of Bamboo builds

Step 4: Release automatically if set up as a Deployment and manually if set up as a Delivery.

Figure 6. Email Notification: Release of automated deployment using Atlassian Bamboo

Step 5: Take advantage of the linkage

Figure 7. Linkage of deployment release to specific Jira tickets

Note that one Jira ticket has been resolved between Development (1.11) and Production (1.5).

Conclusion

In this investigation, we delved deeper into the concept of Continuous Deployment and Continuous Delivery systems. By setting up CI/CD we enable our team and/or customers to review our package deliverables, regardless of the stage we’re at. This process encourages greater collaboration and transparency across the team and to one’s customers.

Would you like to find out more about how Altium can help you with your next PCB design? Talk to an expert at Altium or continue reading about using integrated PCB libraries and schematic capture with Altium Designer^®.