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.
