Onboarding a Repository Manager
Onboarding a Repository Manager
Here are a few things to keep in mind when adding a binary repository manager into your SDLC.
Join the DZone community and get the full member experience.Join For Free
So, you’ve decided to add a binary repository manager into your SDLC/CI (Software Development Life Cycle). Here are some key points and high-level aspects you need to consider before getting started.
Top five areas to think about prior to and during implementation:
Infrastructure and Topology
Content and Tools
Utilization in the CI/CD Process
Leveraging Added Value in your Dev Processes
Management and Maintenance Procedures
1. Infrastructure and Topology
Here are the first two aspects for your foundation:
System requirements of the machine that will run the new application. This include, resources, network, and storage.
Physical location of the application in your organization.
Some questions you will probably want to ask yourself:
- How many servers do you need?
- Where will they be located?
- How will they communicate with each other and the outside world? Are they within an isolated environment (Air-Gap)? Are they physically distributed (multi-site topology)?
2. Content and Tools
To get started, you’ll need to connect your dev-stations and existing resources, including package managers and CI servers (such as Jenkins CI for example), to work with the application.
If you don’t have a CI integration or your organizational procedures require you to configure package managers and build tools on individual workstations, some applications do provide you with easy to use setup features, such as build-tool configuration snippets/templates for example. In most cases, you’ll need to consider scripting or other ways to automate the on-boarding of workstations to work with the new tool. It is important to ensure a seamless integration with minimal interference for your end-users as possible.
Many tools can integrate into your build ecosystem and allow you to gain visibility into your artifacts, dependencies and information on your build environment.
3. Utilization in the CI/CD Process
Introducing a binary repository manager into your CI/CD pipeline will most likely take the longest time to plan and implement. You’ll want to do this with as least interference with your end-users and system as possible. Here are some tips to keep in mind:
Choose your most agile team (i.e. the team that will be most open to changes).
Choose a project maintained by this team. Preferably a new project so that you will not need to modify an existing build/job but rather begin the integration of repository manager from a clean slate.
Keep in mind that in most cases teams are not isolated. Meaning that each dev-team is both creating and consuming content from/for other dev-teams. In turn, this means that you need to make sure that introducing a repository manager (or any system for that matter) will not affect this bi-directional content “transfer.”
Here’s an example of a common process:
Set up your new binary repository alongside your current system.
Configure your builds to start pushing content, including builds and artifacts, to the binary repository while still maintaining your old system. i.e retrieve/deploy to your legacy system but in parallel also deploy to the new binary repository manager.
Start deploying and retrieving content directly to/from your binary repository. But at the same time continue to deploy your content to the legacy system, for the consumption of other teams/projects.
Once you are ready and confident with your binary repository integration, start migrating your projects one by one or in bulk.
Note: The above process assumes that the newly introduced binary repository manager is universal and will act as your single source of truth for your binaries. Also, these are very high-level abstractions and will probably need to be adjusted for your specific use-case.
4. Leveraging the Added Value
Some of the inherent added value of introducing a binary repository manager into your environment is improving the build process. For example, utilizing your build info and metadata will allow you to have traceable builds and easily configured retention procedures.
Having traceable builds will prevent the delay of the build process by stages like compliance, security and release management. This will allow you to separate the development process from the post-development stages such as QA, compliance, and security. And yet maintain a bidirectional connection between all of these post-development steps.
5. Management and Maintenance
In general, a binary repository manager will reduce the ongoing management of your entire build processes/pipeline.
Five maintenance domains you’ll need to plan for:
Retention Policies for your artifacts and Builds information (BOM manifests or other build-related meta-information).
Database management (in case your binary repository manager uses an external DB).
Ongoing system monitoring.
Upgrades and scheduled maintenance operations.
The five aspects we covered in this post should be considered when introducing a binary repository manager. They can also be applied to any other DevOps automation tools for that matter in your dev environment. This summary of suggestions is based on real use-cases, personal interactions, and discussions I’ve had with many users throughout my years as a Solutions-Engineer @JFrog.
Opinions expressed by DZone contributors are their own.