But as we install from git source (see the buildcode here then it should be the same process as you would use to update it if you installed yourself using git source. I would guess that GitLab provide documentation on that.
Please let us know how you go as I'm sure other users would benefit from the info. If you have any issues also post back. I'm not sure I will be able to solve them but I'll have a crack at giving you a hand.
- TKLX GitLab is installed using MySQL whereas the GitLab.org supported community edition VM / builds are based on PostgreSQL. MySQL is only available as an option on the GitLab.org Enterprise Edition.
- TKLX provides initial builds of VMs but does not life-cycle the VMs...you have to do that yourself. Because the TKLX VM is based on MySQL it was obviously not built using the GitLab Omnibus installer. That means you will also need to manage the upgrade of support components yourself (e.g. Rails).
Recommendation:
GitLab is a complex soup of technologies that have been shifting around quite a bit before and after the release 7.11 used in TKLX 14.0 GitLab. For example the GitLab CI was integrated into the core as of release 8.0.
If you choose to use the TKLX GitLab VM use it in situations where you do not expect to upgrade it such as local development.
If you want to use GitLab in a commercial settings and continue to take advantage of bug fixes and enhancements, use the TKLX Core VM and the GitLab.org Omnibus installer (brush up on your PostgreSQL and HAML!). Note that you will have to review the TKLBAM directories to ensure that any new directories are captured in the backup process.
Caution:
Since version GitLab 7.10 apt-get install / update has been supported. I would be surprised if running apt-get install / update against the TKLX installation would work as desired given the MySQL vs. PostreSQL difference. I haven't tried it though.
The TKLX team might have more insight as they are the ones that designed the installation process.
In the past GitLab could be updated using upstream's instructions and it worked fairly well. However it sounds like things have changed a lot in GitLab world since I last had much to do with it (~1.5 years).
The work I did on the GitLab appliance update for v14.0 was only the simple stuff. Anton did most of the update and IIRC he essentially just updated what we had before to make it work. If anyone wants to inspect the installation process more closely then check out the GitLab TurnKey TKLDev build code repo.
However; from your input Tim it sounds like you are well versed in GitLab. Perhaps we would be better transitioning to upstream's recommended installation process? Generally that's what we aim to do; however when upstreams process changes (but ours still works) we have a tendency to just update our existing code. Sometimes that's fine and we always (usually) get it to work fine; although generally it's not ideal IMO. It sounds like using Postgres instead of MySQL might be a good first step?
I agree Jeremy with your observation "Perhaps we would be better transitioning to upstream's recommended installation process".
24 months from now GitLab will have settled down and a TKLX-centric / MySQL installer could be put in place again.
But for the next 24 months I expect GitLab will continue to enhance at an agressive rate and will drift away from the MySQL-centric TKLX 14.0 release. TKLX GitLab 7.11-based 14.0 VM was just released and it is already behind with GitLab v8.x adding integrated CI support. Mattermost "slack-like" collaborative environment will likely be in before the end of the year.
Tim's TKLX VM Selection Rule of Thumb:
Some applications fit the TKLX appliance model better than others.
Best fit:
1a) Stable application with no priority 1 bugs outstanding and an incremental enhancement roadmap on a 2-year cycle
1b) Application is reasonably stand-alone with few if any framework dependencies or has dependencies on components that are core components of a TKLX VM such as MySQL and php that are reasonably stable over a 2- year enhancement roadmap.
Less Attractive fit:
2a) Application that is constantly being developed and goes into and out of commercial grade stability on a release-by-release basis
2b) Application that is quite stable but has an agressive enhancement roadmap on a 6 month cycle.
2c) Applicaiton that has dependencies on components that are not TKLX core components.
GitLab is category 2b/c. The releases are all high quality but there is a reliance on non-standard TKLX components such as Rails and the GitLab enhancement roadmap is aggressive with major feature changes and significant application component re-writes every 6 months.
I chose to standardise on TKLX Core VM with a GitLab.org Omnibus install rather than use the TKLX GitLab VM. Works great, stability and quality are high and I can update it with:
We could look to releasing TKLX GitLab 14.1 appliance based on the GitLab.org Omnibus installer but it would probably be better to figure out a way to stick with the MySQL install to avoid having to sort out a database migration path from TKLX 14.0 - 14.1. Plus, a free MySQL-based GitLab is a unique offering since you need to go to GitLab Enterprise for MySQL support (for people who prefer MySQL to PostgreSQL).
Unless this post inadvertently scares people away from the TKLX 14.0 GitLab VM in which case should probably go native install with PostgreSQL.
I haven't tried...
Please let us know how you go as I'm sure other users would benefit from the info. If you have any issues also post back. I'm not sure I will be able to solve them but I'll have a crack at giving you a hand.
Upgrade with caution
Hi Emil,
GitLab fast facts:
- TKLX GitLab is installed using MySQL whereas the GitLab.org supported community edition VM / builds are based on PostgreSQL. MySQL is only available as an option on the GitLab.org Enterprise Edition.
- TKLX provides initial builds of VMs but does not life-cycle the VMs...you have to do that yourself. Because the TKLX VM is based on MySQL it was obviously not built using the GitLab Omnibus installer. That means you will also need to manage the upgrade of support components yourself (e.g. Rails).
Recommendation:
GitLab is a complex soup of technologies that have been shifting around quite a bit before and after the release 7.11 used in TKLX 14.0 GitLab. For example the GitLab CI was integrated into the core as of release 8.0.
If you choose to use the TKLX GitLab VM use it in situations where you do not expect to upgrade it such as local development.
If you want to use GitLab in a commercial settings and continue to take advantage of bug fixes and enhancements, use the TKLX Core VM and the GitLab.org Omnibus installer (brush up on your PostgreSQL and HAML!). Note that you will have to review the TKLBAM directories to ensure that any new directories are captured in the backup process.
Caution:
Since version GitLab 7.10 apt-get install / update has been supported. I would be surprised if running apt-get install / update against the TKLX installation would work as desired given the MySQL vs. PostreSQL difference. I haven't tried it though.
The TKLX team might have more insight as they are the ones that designed the installation process.
Hope that helps.
Cheers,
Tim (Managing Director - OnePressTech)
Thanks Tim
In the past GitLab could be updated using upstream's instructions and it worked fairly well. However it sounds like things have changed a lot in GitLab world since I last had much to do with it (~1.5 years).
The work I did on the GitLab appliance update for v14.0 was only the simple stuff. Anton did most of the update and IIRC he essentially just updated what we had before to make it work. If anyone wants to inspect the installation process more closely then check out the GitLab TurnKey TKLDev build code repo.However; from your input Tim it sounds like you are well versed in GitLab. Perhaps we would be better transitioning to upstream's recommended installation process? Generally that's what we aim to do; however when upstreams process changes (but ours still works) we have a tendency to just update our existing code. Sometimes that's fine and we always (usually) get it to work fine; although generally it's not ideal IMO. It sounds like using Postgres instead of MySQL might be a good first step?
GitLab will be a bit of a challenge for TKLX for about 24 months
I agree Jeremy with your observation "Perhaps we would be better transitioning to upstream's recommended installation process".
24 months from now GitLab will have settled down and a TKLX-centric / MySQL installer could be put in place again.
But for the next 24 months I expect GitLab will continue to enhance at an agressive rate and will drift away from the MySQL-centric TKLX 14.0 release. TKLX GitLab 7.11-based 14.0 VM was just released and it is already behind with GitLab v8.x adding integrated CI support. Mattermost "slack-like" collaborative environment will likely be in before the end of the year.
Tim's TKLX VM Selection Rule of Thumb:
Some applications fit the TKLX appliance model better than others.
Best fit:
1a) Stable application with no priority 1 bugs outstanding and an incremental enhancement roadmap on a 2-year cycle
1b) Application is reasonably stand-alone with few if any framework dependencies or has dependencies on components that are core components of a TKLX VM such as MySQL and php that are reasonably stable over a 2- year enhancement roadmap.
Less Attractive fit:
2a) Application that is constantly being developed and goes into and out of commercial grade stability on a release-by-release basis
2b) Application that is quite stable but has an agressive enhancement roadmap on a 6 month cycle.
2c) Applicaiton that has dependencies on components that are not TKLX core components.
GitLab is category 2b/c. The releases are all high quality but there is a reliance on non-standard TKLX components such as Rails and the GitLab enhancement roadmap is aggressive with major feature changes and significant application component re-writes every 6 months.
I chose to standardise on TKLX Core VM with a GitLab.org Omnibus install rather than use the TKLX GitLab VM. Works great, stability and quality are high and I can update it with:
sudo apt-get update
sudo apt-get install gitlab-ce
We could look to releasing TKLX GitLab 14.1 appliance based on the GitLab.org Omnibus installer but it would probably be better to figure out a way to stick with the MySQL install to avoid having to sort out a database migration path from TKLX 14.0 - 14.1. Plus, a free MySQL-based GitLab is a unique offering since you need to go to GitLab Enterprise for MySQL support (for people who prefer MySQL to PostgreSQL).
Unless this post inadvertently scares people away from the TKLX 14.0 GitLab VM in which case should probably go native install with PostgreSQL.
Cheers,
Tim (Managing Director - OnePressTech)
Add new comment