I created a project using Php and in the project source have an environment file (env.php) where I stored credentials and all, so my question is that I want to use the opensource Gitlab for a very first time and I will create a repo on gitlab.com right and then I will push my source to the particular repo
1 . Does my source will be safe on Gitlab ? if I created in free version
2 . Should I ignore my env.php file from development pc when I push to the gitlab ? or can push with env.php file
what’s the best practice to collaborate with the gitlab opensource ?
@kaushal_nec
Hi,
never add any file to Git which contains passwords, credentials or would expose any details about your company. This also includes database schema naming, structures, etc.
If you are planning to use private repositories, this may be an option. Still, if you are using these credentials for these purposes:
- Local development environment
- CI jobs publishing the site and running it somewhere with Ansible/Terraform
I strongly recommend to store credentials in a safe place instead. A password safe where your developers have access to and can modify env.php on their local environment for example.
For automated deployments, use vaults or different safe locations when adding this to your server environment.
Cheers,
Michael
2 Likes
Hi @soldierMartin,
If I go through your first question then my answer is “Yes”, because GitLab-CE provide a free hosting for your source code (Used by other members if you make the project visibility to “Public”).
And for second one, if you add any file to a project which is related to your confidential information, then ensure that the project should be “Private” but not “Public”.
From my point of view, there are some basic points mentioned below that need to be take care for best practice to collaborate with GitLab:
Share project as broad as possible. Exceptional case for the project that requires a higher level of security on a case-by-case basis.
Spread heavy workloads across geographically distributed developers or even with non-developer team members.
Use forks and branches so developers can try different changes without affecting original projects.
Make each step in the software development lifecycle (such as testing and deployment) visible to everyone.
Add README guide to all repositories to help everyone understand basic usage and visibility of project.
Update in-code documents on regular basis to keep user manuals in sync with the latest version of the code.
Warm Regards,
Kaushal
2 Likes
