Planning
Last updated
Last updated
As with any system, planning on how to use the system will benefit your productivity in the long run. In this section, we will walk you through the initial steps of understanding how to best use Copia in your environment.
First off, you need to identify what "type" of customer you are. There are generally two types of customers that will be using Copia, and these are "End Users" or "SIs and OEMs".
End Users End Users are engineers, technicians and maintenance teams that use automation to make or manage a product at a factory or in the field. Examples may be an automobile manufacturer making cars, a utility managing water supply, or a company that mines for minerals.
System Integrators & OEMs (or a corporate engineering team) This type of user is typically involved in creating machines or control systems to be used by the end users. In addition, this type of user may be involved in the maintenance and support of those machines or systems at client locations.
Based on the roles and action you perform, your needs may fit better into one or the other types above, and as such, will help us to guide you along in the next step of planning.
Now that you know your type, one of the first things to consider is how you you will organize your data into repositories. Until now, you probably have been using a folder-based tree structure to organize this data. Git uses another approach called "repositories" which are like folders, and Topics to organize those repositories. This provides greater flexibility to quickly search and find your data, while still allowing you to work in a folder structure locally.
End Users are more likely to be working with a geographical or hierarchical structure for their project data. In these cases, we generally recommend mapping the folder/tree structure to Copia in a manner similar to the example below (based on the Centralized Workflow of Git). This makes use of Topics, which allow you to define a repository and quickly search and navigate Copia easier than a legacy folder structure.
As seen in this example above, the Shrink Wrap Lines each may contain multiple PLC, HMI and Drive projects. As such, it may be common to set each up as a individual repository. This would allow you to Clone (make a copy) of each repository locally to make changes, and push to the server as needed.
Alternatively, if you are the Engineering Lead in Packaging, perhaps it makes more sense to create a single repository for "Packaging", and have the 3 lines as sub-directories. The system is flexible to allow you to organize this as you see fit.
Keep in mind, Copia is based on Git which is distributed. This means that a Clone (or copy) of the repository will be maintained on your local PC for work to be performed. As such, setting a Repository at the "Plant-1" or "Shipping" level is not recommended.
System integrators or OEM's may be building machines or control systems for use by end users. As such it is more typical for then to create a Repository per system or machine. Branching (or additional repo's based off of a template) can then be used to reflect variants or types of those systems or machines. (this approach is based more on the Feature Branching workflow of Git)
An alternative approach may be a repository for Clients as well, so that you can track the versions of a system/machine that was delivered or deployed at a client location.
Git will not allow you to use spaces when naming repositories, so use dashes and underscores as needed. Remember to be specific and consistent with your naming conventions.
It is important to establish a set of common workflows before starting a project, and communicate these with your teams. This will ensure that all users are aligned on how changes will be applied.
Here are our top tips to streamline your workflows:
Make clean, single-purpose commits
Write meaningful commit messages
Check which branch you’re on before committing
Commit early and often to increase revert options and clarity on individual changes
Copia allows (and encourages) collaboration on projects. This is typically done through branching and merging. Branching and merging is one of Git’s most complex and powerful feature sets. It may be worthwhile to review how Branching, Branch Protections and Merging works and set some initial rules in place for how you use these processes when starting out.
For a detailed look at branching and merging, check out the Branching section.
Many different Git workflows have been defined over the years, but the examples above are based on the two workflows below, which are very popular. This information is provided to give more understanding of how they work.
One of the most popular or common workflows for end users is to designate a specific repository as a “central” repository. This repository can contain the data for a single machine, line or area (which ever makes most sense for your organization). You can have one or many of these repositories.
The centralized workflow is the easiest workflow to adopt for teams new to Git. With this workflow, all members with access (who may be part of a Team in Copia) can make a local clone (or copy) of the repository. They are then able to edit files and make local commits without affecting the central repository. When a developer is ready, they can push all of their local commits to the central repository.
In this way, the central repository acts as a "source of truth" and single point for all changes to the project. Within the central repository is the main branch where all changes are committed to.
In addition, users can "protect" the source code, so that approval is needed to update it, to provide an extra level of review and security.
Feature branching may be more appropriate for those users who have a specific machine or system type, such as an SI or OEM. In feature branching, dedicated branches are used by developers to work on features or variants, without disturbing the main branch. Each branch is tied to a particular feature and is often denoted by clear and consistent naming. Developers can edit, commit, and perform pull requests on the branch until the feature is complete.
Since multiple developers may be working on the same feature, the feature branch should be pushed to the central repository. This provides both a remote backup of local changes and access to multiple team members who may be involved in the feature development.
This workflow caters to continuous integration (CI) environments because it ensures that the main branch will never be corrupted by broken code.
