Best Way To Manage Code Repositories For multiple ASIs

Manage Code Repositories

 

Introduction

 

In today’s digital age, managing code repositories (source code and associated documentation) are the lifeblood of many businesses. They contain the instructions and blueprints for the software and applications that drive operations, support customers, and generate revenue. As a result, losing access to these critical assets can have disastrous consequences, from downtime and data loss to security breaches and compliance violations.

 

To address these risks, an Enterprise System Integrator (ESI) will implement a set of policies aimed at safeguarding the source code and documentation of its customers. These policies require deliberate actions, such as regular backups, version control, access controls, and disaster recovery plans, to ensure that the code and documentation are protected against loss, corruption, theft, or misuse.

 

One of the key provisions of these policies is that the source code and documentation remain the property of the customer, even if they collaborate with third-party Application System Integrators (ASIs) to develop or maintain their software. This means that the customer retains full control and ownership over their intellectual property and can decide how to share or license it with others.

 

However, this provision also implies some potential challenges and limitations for both the customer and the ASIs. For example, the customer may need to ensure that their ASIs comply with their policies and standards, which may require additional due diligence, training, or auditing. The customer may also need to negotiate the terms and conditions of their relationship with their ASIs, such as the scope of work, the ownership of the derived work, and the liability for any breaches or damages.

 

On the other hand, the ASIs may face some restrictions and dependencies on the customer’s code and documentation. For example, they may need to adapt their development tools, processes, or methodologies to fit the customer’s requirements, which may incur additional costs or delays. They may also need to collaborate closely with the customer’s IT or legal teams to ensure compliance with the policies and regulations, which may require more communication and coordination.

 

Overall, the ESI’s policies reflect a balanced approach to managing the risks and benefits of source code and documentation in a complex and dynamic environment. By encouraging deliberate actions and clear ownership, the policies can help mitigate the risks of loss and misuse while promoting innovation, collaboration, and value creation.

 

Define the code management requirements

 

The following are the requirements set by the Enterprise System Integrator (ESI) for Application System Integrators (ASIs) to develop source code:

 

• Utilize and maintain an industry standard-based source code management system following industry best practices for source code control. Approved source code should include the following features:
  • Authenticated access for commits to know who committed changes
  • Authorized access to define access control rights by the ASIs
  • Versioning support – most version controls use incrementing numbers
  • Revision history on files to meet CUSTOMER audit requirements
  • Atomic commits to support multi-file check-in
• Maintain version control for source code assets to support recovery from prior versions.
• Maintain all necessary documentation related to the appropriate source code assets. Documentation should include, but is not limited to, technical specifications, business requirements, change requests, and release notes.
• Maintain appropriate segregation of responsibilities between developers and code reviewers at a level necessary to protect the source code from unauthorized changes.
• Manage deployments consistent with CUSTOMER change management policy which requires CUSTOMER written approval prior to any source code migration to production.
• Protect source code from unintended loss by:
  • Ensuring that production and test code cannot be altered without appropriate approvals
  • Ensuring that backup copies of the source code management system are performed daily and rotated to off-site protected storage.

 

 

Define the Unified Code Management Guidelines

 

1. Code Repository: It is recommended to have a single code repository for CUSTOMER systems that can manage source code across multiple ASIs.
2. Access Privileges: ASIs are responsible for managing access privileges and provisioning access rights for the code repository.
3. Comments and Requirements: ASIs are responsible for providing comments for each commit to the source code. These comments should include links to requirements.
4. Testing: ASIs are responsible for making sure that the checked-in code contains test suites that address the requirements and submit test reports.
5. Continuous Integration: ASIs are responsible for configuring continuous integration (CI) jobs, as mentioned in Section DevOps. This will ensure that the deployed projects run through test suites and are validated before deploying to the application server.
6. Code Quality: ASIs should ensure the quality of code for platform-shared service components only (with appropriate supporting documentation). This can be achieved by conducting code reviews with respective team leads before migrating code to higher environments.

 

 

With the above guidelines, unified code management across multiple vendors results in improved code quality, increased collaboration, and easier maintenance.

 

Version Control

 

Organizations rely heavily on version control systems to manage their application code base, which is typically spread across multiple vendors. Since considerable effort and time is invested in developing these applications, it is critical to protect these assets. In a multi-vendor environment, IT policies should be implemented to prevent overlap and merge conflicts when multiple resources are working on the same code base. To ensure that source code management systems are effective, they should include features like authenticated access for commits, revision history of files, atomic commits of multiple files, and versioning and tagging. In addition to version control systems, it is also necessary to have a separate build artifact repository to store release builds. To ensure that release builds are protected, they should have authentication and authorization access.

 

Best Practices

 

 

Item	Details
Commit logical changes together	It is best practice to check in all changes related to a given bug at the same time. This way, it is easier to roll them back if something goes wrong. It is always good practice to connect related changes by referencing the change request number. This helps even if code is submitted to two different branches or repository managers.
Avoid committing partial changes	Each developer is responsible for committing code only when work is completed. However, developers may commit partially completed logical working code within a large implementation. This helps avoid any collaboration issues with other developers by sharing some of the common artifacts within the source.
Test changes before committing	Testing changes before committing them can be challenging while working on large implementations with multiple vendors or multiple practices by the same vendor. However, each developer should make sure the code is unit tested thoroughly and include appropriate comments when committing. This helps code reviewers understand changes, provide feedback into improving the overall code base, and provide guidance to future code reviews.
Add comments for each commit	Adding comments each time a change is committed helps technical leads and other developers understand the reasons the changes were made. It is best to indicate if the change is: New For a specific use case or requirement Bug-related Related to a change request
Do not use the repository as a backup system	Version Control is for build stream code and is not to be used for file backups.
Avoid conflicts	Version control systems can merge simultaneous changes made by different users. A conflict occurs when two different users make different changes to the same line of a file at the same time. When this happens, the version control system cannot merge the changes automatically and manual intervention is required to resolve the conflict. Committing often keeps the number of files to commit small and keeps related changes together. It allows for more frequent code sharing with other developers. This way it is easier for everyone to integrate changes regularly and avoid having merge conflicts.

 

Branching

 

• The SDLC involves regular releases for almost every project due to bugs or ongoing enhancements.
• Assigning priority to each reported bug helps to keep individual releases stable.
• Complex bugs can cause release delays, which is why branching at each major project milestone is important.
• Running several development threads in parallel can help to avoid delays caused by complex bugs.
• Using branches for each major release can address the above issues.
• Changes in one branch must flow to other branches, but without rules and guidance, propagating changes can lead to instability.
• Unintentional overwriting of existing changes, merge conflicts, and lost updates are some of the issues that can arise.
• Different branching models are available, and the following sections describe these models, their issues, and how to address them.

 

 

Trunk Release

 

The trunk is often referred to a master or main release. On most projects, there is a single code base for all developers which is derived from code repositories. The code base is a piece of software which is produced with a set of files. Every code base consists of a range of individual changes.

 

 

Branching out Milestones

Code repositories help in branching milestones which occurs quite frequently.

• It’s a good idea to create branches for major releases to work on development and bug fixing simultaneously.
• Sometimes, new code releases or bug fixes are not initially stable.
• To maintain project timelines, it’s important to keep working on new enhancement requests even while stabilizing production releases.
• To avoid halting new development tasks and changing policy on the code line, it’s recommended to branch the release code line, which usually happens at code freeze.

 

 

 

Hotfix Branches

 

Hotfix releases are emergency fixes made to production release branches and use code repositories. Hotfix branches should be created from the production release branch. After completing the fix, the changes should be merged into the release and development branches.

 

 

Now we have seen the various ways for code repositories. You can build one for DevOps too and draw out similar flows. Check out more of these blogs by checking back regularly.

 

Authored by Vijay Chander – All rights reserved 2023