How We Manage Source Code

Source Control

We store all source codes in professional source control systems. These systems are located in a secure, professional hosting environment. We use Git Lab as our primary source control system. We manage access rights separately for each project, and access to the source control system is excusively via a configured VPN. External developers have only limited access to source codes.

Source Code Change Procedure

The source control system (Git Lab) stores source codes for all D3S projects. The general guidelines recommended for all projects are as follows:

When submitting code to the source control, developers should comment on the submitted code; their comments must include the issue number from Gemini for easier traceability of the requirement.

Developers are permitted to submit only working code (see the Implementation Checklist). For temporary storage of source code, we use the shelving feature of Git Lab.

Developers are not allowed to submit source changes to production build branch of the source control. Instead, they must use development branches and merge the change later.

Continuous Integration & Build

To support automated application deployment, all projects use Continuous Integration and Build on a dedicated build machine.

Version Management

Our software development plans for major and minor versions includes project milestones, resources, dependencies, and risk management.

Click here to learn about how we plan and manage new versions of our software products.

Implementation Checklist

We provide the following checklist as guidance for all developers to help them manage and check their own work:

  • Coding complete

This includes source code, as well as database scripts, etc. Always submit complete and working code.

  • Check completeness against requirements

Read again what was required and compare with what you have implemented.

  • Compare your changes

Compare changes against previous version (both code and database scripts) before submit. It is a good practice to separate source code for an issue from the other files. Revert unchanged files and ensure you submit all necessary files.

  • Run a “Turkey Test”

If there is a change your code will run in another language, with a non-Latin alphabet, or in non-Latin environment, check your code carefully. In Turkish, for example, the letters i and I are different. This applies also for databases. If you have a database with a Turkish collate, always check the query on this database.

  • Run the code in the debugger/write unit tests

Never think your code will work without being tested.

  • Run code analysis and correct findings

Run the code analysis in Visual Studio and fix relevant warning/errors.

  • Create/update internal technical documentation

Create or update relevant info (e.g. new settings, behavior, new screenshots).

  • Test the final code at own developer machine

Test the scenario at your own development machine.

  • Consider getting a code review (with findings processed)

Think about the risks of your code changes. If you are not sure, ask for code review.

  • Consider creating load test/create a load test

Think if a load test is necessary or required.

  • Consider writing and automated UI test/create one and run it

Think if you can use automated UI test.

  • Update build configuration

Check if you need to update deployment parameters. Check if default configuration is ok.

  • Submit to source control with recommended label

Submit source files with issue number. Do not submit database scripts and source code together, split them into two submits. Submit separately also technical documentation update.

  • Ensure the build of your code succeeds

Check central build complete successfully with you change.

  • Log time spent on the issue

Do not forget to report your time on the issue. This should be done every day if the task is longer.

  • Update issue status in Gemini (ticketing & issue management system)

Set implemented status for the issue you have just finished.

Code Review

We perform Code Review either during development, prior to submission of code to the source control, or after submission to the source control by evaluating the changes to the source code against the previous version.

We perform Code Review for any code that impacts system-wide functionality or the degree of availability, integrity, confidentiality, speed, memory consumption, users, API, and security. We use a risk matrix to help determine when code reviews are required.

We also conduct code reviews any time an assigned developer and/or their Team Leader thinks code review may be required. We encourage all developers to have their code reviewed regularly or with each submission, regardless of the classification of the submitted code.

General Approach to Testing

Our general strategy is to have developers test their work (especially deployed applications) before they hand it off to testers. Testing of a given developer’s work is conducted by another developer with similar or related skill-set and availability. This is typically a member of the same team as the developer who is assigned the work. This approach radically improves the quality of testing and decreases the number test iterations.

Click here to read more about our test methods and procedures.

Share on facebook
Share on twitter

Request a Personalized Demo

Learn how to improve customer engagement and boost sales team performance with Inception CRM.

Inception CRM for Pharma

Get in touch for a personalized demo to see how Inception CRM can improve your sales

Inception CRM saves sales teams time while increasing their productivity, effectiveness, and efficiency.