The Datastores team owns our persistent storage platforms in GitLab, namely our PostgreSQL databases (our main priority) and our Gitaly backend service.
PostgreSQL Databases we look after in Gitlab:
Other components we take care of, as part of the Database ecosystem in Gitlab:
Gitaly components we maintain:
|Alberto Ramos||Engineering Manager, Reliability|
|Alejandro Rodríguez||Site Reliability Engineer|
|Ahmad Sherif||Site Reliability Engineer|
|Henri Philipps||Senior Site Reliability Engineer|
|Jose Cores Finotto||Staff Database Reliability Engineer|
|Nels Nelson||Site Reliability Engineer|
|Open Position||Database Reliability Engineer|
Run our production systems on Software. Love and protect the data that powers GitLab; losing data is simply game over.
We create, plan and execute our work based on 2-week Iterations, mostly in an asynchronous way.
We create work via:
To create a new Datastores issue:
New Issue, and on the
Templatedrop down select
A team member looking for the next issue to work on should look at:
We use the following definition of done. Your contribution is not done until you have made sure it meets all of the requirements stated in the issue/epic Acceptance Criteria section, as in this basic example.
Every issue/epic must include this. If at the time of creation the criteria is not clear, or if the issue is being created by an external reporter from whom we don't expect that level of specificity, the definition of done should be included before starting work on the issue/epic. Make sure all the checkboxes are ticked before you call the issue/epic "done".
Our async fortnight planning process looks like this:
Every two Mondays the team has the "Datastores Team catch up (or iteration planning)" call, we where we can do sync iteration planning and refining - in addition to our Iteration Planning Issue async planning.