Auto DevOps (Beta)
This meta issue has the goal to discuss and track development of the first iteration for Auto DevOps (#35712 (closed)) that will be released in %10.0. This will probably be marked as BETA and not enabled by default for all the projects, but we want it to be very easy to discover and to enable for everyone.
Since many other issues were opened about specific topics, here we can have a summary and discuss about the general process. Relevant comments from other related issues will be reported here.
Steps that will be covered are:
Auto Build will create the application starting from sources. It can be achieved in two different ways:
- if there is a
docker buildcommand to create an image
- otherwise, try to use herokuish buildpacks to automatically detect and build the software
Auto Test will support automatic testing of the application based on herokuish buildpacks extensions to test.
This is covered in #26941 (closed), by extending herokuish or using a customized version.
Auto Code Quality
Auto Code Quality run
codeclimate engines on the current code, creating reports that are uploaded as artifacts. In GitLab EE differences between source and target branches are shown in the MR widget.
Note: Implementation is already done but can be improved to avoid
dind and related problems (#33266 (closed)).
Auto Review Apps
Auto Review Apps are created for each branch. This can be done with actual version but needs to be added to the configuration file.
Auto Deploy deploys current application to Kubernetes (OpenShift will be not supported) if a cluster configuration is available. This is an optional step, since most of the projects will not have a Kubernetes cluster available.
Auto Deploy should not include deployment to staging or canary deployment as a default, but as an optional job that can be uncommented if needed.
To avoid creating a job that fails because of the absence of a cluster, a new
.gitlab-ci.yml syntax will be added so it can automatically detect if the cluster is available or not (#34785 (closed)).
Note: despite of old Auto Deploy template that relies on an "opaque" Docker image that contains high-level commands, we want to make it explicit in the
gitlab-ci.yml so people can understand, adapt and contribute. This requires to flatten all the logic in the file, and it is covered in #29412 (closed).
The first implementation of Auto DevOps will consider the following aspects:
.gitlab-ci.ymlfile that implements all the above steps: #36870 (closed)
- Automatically enable this file for projects (UX and configuration): #34777 (closed)
- Documentation about how Auto DevOps works (technical aspects): #37051 (closed)
- Demo video: gitlab-com/www-gitlab-com#1599 (closed)
- Sort templates: #37153 (closed)
codequalityjob: gitlab-ee#2783 (closed)
codequalityin Auto DevOps template (after gitlab-ee#2783 (closed))
Considerations on how Auto DevOps can impact on GitLab.com are in gitlab-com/infrastructure#2632.
Links / references
Auto/Integrated DevOps (#35712 (closed))
Create a .gitlab-ci.yml file for Auto DevOps (#36870 (closed))
- Rails template should use Postgres (#37156 (closed)) Stretch
- Auto Deploy doesn't use versioned images (#34833 (closed))
- Skip jobs if no Kubernetes found (#34785 (closed) !13769 (merged) !13849 (merged))
- Add Code Climate to Auto DevOps template (#33266 (closed))
- Make Auto Deploy databases persistent (#32826 (closed))
- Add more database (and other?) services to Auto Deploy helm chart (#32825) Stretch
- Auto Deploy should use helm chart (#30723 (closed))
- Auto Deploy should use project's helm chart, if available (#29969 (closed))
- Flatten auto deploy into single
- Leverage Heroku CI in buildpacks for zero-configuration CI (#26941 (closed))
- Rename codeclimate to codequality (gitlab-ee#2783 (closed))
Integrate usage of an implicit .gitlab-ci.yml for Auto DevOps (#34777 (closed))