CI/CD UX Scorecard: Use Auto DevOps in an existing project without CI/CD configuration
JTBD
When I have an existing project without CI/CD configuration, I want to use Auto DevOps, so I can use modern devops workflows on my project with minimal effort
Checklist
-
Document the current experience of the JTBD, as if you are the user. Capture the screens and jot down observations. Also, apply the following Emotional Grading Scale to document how a user likely feels at each step of the workflow. Add this documentation to the epic's description. -
Use the Grading Rubric to provide an overall measurement that becomes the Benchmark Score for the experience, and add it to the epic's description. -
Once you’re clear about the user’s path, create a click through video that walks through the experience and includes narration of the Emotional Grading Scale and Benchmark Score. -
Post your video to the GitLab Unfiltered YouTube channel, and link to it from the epic's description. -
If your JTBD spans more than one stage group, that’s great! Review your JTBD with a designer from that stage group for accuracy. -
Create an issue to revisit the same JTBD the following quarter to see if we have made improvements. We will use the grades to monitor progress toward improving the overall quality of our user experience.
Emotional Grading Scale
-
😃 Positive: The user’s experience included a pleasant surprise—something they were not expecting to see. The user enjoyed the experience on the screen and could complete the task, effortlessly moving forward without having to stop and reassess their workflow. Emotion(s): Happy, Motivated, Possibly Surprised -
😐 Neutral: The user’s expectations were met. Each action provided the basic expected response from the UI, so that the user could complete the task and move forward. Emotion(s): Indifferent -
😡 Negative: The user did not receive the results they were expecting. There may be bugs, roadblocks, or confusion about what to click on that prevents the user from completing the task. Maybe they even needed to find an alternative method to achieve their goal. Emotion(s): Angry, Frustrated, Confused, Annoyed
Current experience of the JTBD
C (Average)
- Workflow needs improvement, but user can still finish completing the task. It usually takes longer to complete the task than it should. User may abandon the process or try again later.
- Frustration: Medium
- Task Completion: Successful but with unnecessary steps
- Steps to Complete Task: Average complexity
- Test project: https://gitlab.com/rverissimo/jtbd-auto-devops
Getting started |
---|
I have set-up a project on gitlab.com and want to get started with Auto Devops so I can have a complete workflow with minimal configuration. For context, my project was created from a Ruby on Rails template . |
Enable Auto DevOps , as well as Set up CI/CD . I am unsure which one of the options I have to click first, or if they need to follow a specific order so that my set-up succeeds. |
Enable Auto DevOps first because the button is positioned before Set up CI/CD . |
Enable Auto DevOps button and am taken to a new page: CI/CD Settings. The page loads with a scroll to the section I need to work on, which is already expanded. That's super useful, one click less. |
Default to Auto DevOps pipeline . There's a link to the documentation, but I don't want to read it now. I want to keep following the workflow to enable Auto DevOps without having to read anything else. |
|
Continuous deployment to production, Continuous deployment to production using timed incremental rollout, and Automatic deployment to staging, manual deployment to production. I don't quite understand the difference between them, and the (?) icons positioned next to each label link to a new page. I'd expect that hovering those icons I could read some sort of excerpt that clarifies each strategy. This is not the case. |
I click on Learn more about Auto DevOps and am taken to a documentation page. |
Following the documentation for set-up |
---|
.gitlab-ci.yaml , so I really think need to configure this firs. |
|
|
|
|
Adding a Kubernetes cluster integration |
---|
|
|
|
Add Kubernetes cluster . That's really interesting. Why wasn't this button positioned before Enable Auto DevOps then? I go back to my project and click Add Kubernetes cluster . |
|
Sign in with Google , and choose my google account I want to use for this setup. I am then taken back to GitLab, but this time I need to enter the details for my Kubernetes cluster. |
|
|
Select a project and there I can see that I am already added to two GitLab projects. I'm glad I don't have to configure anything here! I close the page and move back to entering details for my cluster on GitLab. |
jtbd-ux , leave the environment scope as is (although I am unsure what that means). I select gitlab-internal in the Google Cloud Platform project dropdown. |
Zone sounds a lot like Time Zone , but I am pretty sure that's not the case because the options I am given don't look like standard time zones. |
|
|
Zone , when in reality I need to provide a Region . This label might need to be updated. |
europe-west4-a , europe-west4-b , and europe-west4-c . Since I am not sure of the impact this might have, I simple choose europe-west4-a . |
Create Kubernetes cluster button. |
Create Kubernetes cluster button I am taken to a new page: Kubernetes Clusters > jtbd-ux. There is a blue banner that reads: Kubernetes cluster is being created on Google Kubernetes Engine... |
|
|
|
|
|
Installing applications on my cluster |
---|
Install button. |
Install to Installing . And an animated spinner is also shown. This is quite cool, it helps me get a sense of progress. After some time Help is installed and now I can check all other applications. |
Install on both of them. |
|
|
|
Enabling Auto DevOps |
---|
settings > ci/cd in the menu. I'm always confused by these menu options... |
|
Select Enable Auto DevOps but the application UI shows: Default to Auto DevOps pipeline The docs and screenshots really need an update. |
|
Save changes button. |
close to dismiss them... |
I click the link to visit the Pipelines page. |
Fixing my pipeline |
---|
|
|
.ruby-version . I open the file and see the version is set to 2.5.1 . I click the button to Edit the file. |
2.5.5 to 2.5.1 , and commit the changes. |
|
|
|
|
Gemfile.lock . |
2.5.1 . I update with 2.5.5 , commit, and go back to the pipelines page. |
|
|
Gemfile , not the Gemfile.lock . Ok, hopefully this will be the last time I have to do this... project details, gemfile, edit... replace 2.5.1 with 2.5.5 , commit. |
|
|
|
In order to deploy or use Review Apps, KUBE_INGRESS_BASE_DOMAIN variables must be set. From 11.8, you can set KUBE_INGRESS_BASE_DOMAIN in cluster settings or by defining a variable at group or project level. You can also manually add it in .gitlab-ci.yml |
.gitlab-ci.yml file. That's quite an obvious fix. I'm starting to feeling frustrated because I did not expect to manually fix so many small things within this project, that was created using a template. |
+ icon to create a new file. |
.gitlab-ci.yml option as template, and a new dropdown appears: Apply a GitLab CI Yaml template. I select the Auto-DevOps option and the file get populated with a lot of data. Wow! That's really overwhelming, I honestly don't want to configure any of this in order to set-up my production environment. I have no idea where to go from here. I'm really frustrated... |
set KUBE_INGRESS_BASE_DOMAIN in cluster settings . I cancel my changes and try to find the cluster settings in the application UI. |
|
|
jtbd-ux , and a new page loads with the details. I remember this page, it's where I had to set up the applications running in my cluster. Now I see an option to add a Base domain . I go to my Ingress application, copy the IP number I see there, and paste it inside the Base domain option. I then save my changes. |
retry in the Production stage. |
|
|
|
|
I cannot stop thinking that the Auto DevOps quick guide never mentioned I had to go through all those steps! And if it did, it wasn't as visible as it should |
Getting help from the team to understand errors |
---|
gitlab.com . He tested my Kubernetes cluster and could see that is was working properly. The problem is the Ruby on Rails template available at GitLab that does not work correctly with Auto Devops. This is a big problem because we explicitly indicate that the user should use our Rails template, which currently does not work seamlessly for Auto DevOps. This thread in the Configure Slack channel (private) discuss that our project templates are often less likely to work with Auto DevOps by default than newly generated projects since herokuish is not trying to keep support for our project templates . If that is a fact, we should indicate this to users, as well as remove the Ruby on Rails template from the Auto DevOps Quickstart Guide in our Documentation. Either this of fix the bug in the template. |
Node JS Express template for my project. I will need to start the set-up from the beginning with a new project. |
Starting over with a new project template |
---|
|
|
Add a new kubernetes cluster
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Alright! The pipeline for Test and Production passed. Now it's time to check my environments. |
|
|
Recap
-
Final project: https://gitlab.com/rverissimo/rayana-jtbd-cicd
-
Final Benchmark Score:
C (Average)
- Workflow needs improvement, but user can still finish completing the task. It usually takes longer to complete the task than it should. User may abandon the process or try again later.- Frustration: Medium
- Task Completion: Successful but with unnecessary steps
- Steps to Complete Task: Average complexity
-
Creating a project from a template:
😐 Neutral /😡 Negative -
Getting started with CI/CD and Auto DevOps:
😐 Neutral -
Following the documentation:
😡 Negative -
Adding a kubernetes cluster integration:
😡 Negative -
Installing applications on my cluster:
😐 Neutral -
Viewing my pipeline:
😃 Positive -
Viewing my live environment:
😃 Positive -
Troubleshooting:
😡 Negative