It’s my understanding that on-premise deployments of Circle CI enterprise customers will include Circle CI
PARTNER Orbs, along with the ability for enterprise customers to publish their own Orbs to their on-premise registry instance.
The organization I belong to is evaluating Circle CI Enterprise as an option for an on-premise CI solution.
During our early meeting with Circle CI we discussed how best to work with Orbs so that we could quickly, and easily, migrate projects using an on-premise Circle CI instance, to CircleCI_com.
For a little background, our organization is looking to shift a large quantity of source code repositories to GitHub_com from our internal SCM platform. Some repositories will be kept private, while others will be made public under an Open Source license.
If we adopt Circle CI Enterprise as our on-premise CI solution, our internal source code repositories would be restricted to Orbs published to the on-premise Orb registry.
If an internal repository is migrated to GitHub_com and CircleCI_com, Orb references would need to be updated.
PARTNER Orbs this may not be an issue at all, assuming those Orbs are kept in sync with the CircleCI_com registry.
For Orbs developed by our company, the issue is that we’ll need to develop a process that publishes our Orbs to both the public Circle CI Orb registry, and an on-premise registry. This process can be automated. It’ll just require more overhead to maintain, especially if we want to keep the source code for our Orbs publicly available on GitHub_com.
Lastly, there’s the question of how third-party Orbs published on the public Circle CI Orb registry can be made available to an on-premise Circle CI instance (or even, whether they should be, given the security implications).
If they are not made available, our organization may find itself forking publicly available Orbs and re-publishing them internally. If we are able to publish the Orb internally using the same namespace, then projects that migrate to GitHub_com would not need to update those Orbs, or Orb versions. Otherwise, it would require switching the Orb from an internal one to an external one.
The point of this thread is to explore the difficulties we may encounter for projects that first on-board with an on-premise instance of Circle CI, before then migrating to GitHub_com and CircleCI_com. Furthermore, it’s my hope to use this thread to explore practices that could minimize the difficulties in migrating projects from an on-premise Circle CI instance to CircleCI_com.