Now that we have our basics of CI/CD pipelines, how can we put this to the test? Implementation of the pipeline may be daunting at first, but we can start by tackling smaller pieces. An example of a good place to begin the process is potentially with Tableau Server, or maybe even Alteryx Server. I would like to explore the idea of a CI/CD process in Tableau Server a little further here and give thoughts on a light CI/CD process beginning.
Light Beginnings to a CI/CD Process
There are minor steps that can be implemented to begin towards a CI/CD process if a full-blown implementation does not seem realistic. One step is to begin with a platform and a team for a trial run or to mark improvement gains with the new process in place. The next step is to think about the long-term goal of a CI/CD process and what platforms will be intertwined in the process later. We can use the following example of utilizing a JIRA board and Tableau Server environment for a CI/CD process. This is a great example for an analytics team in any industry.
Light Change Tracking
In this example, we’ll be using a JIRA board for validations/testing. JQL can let you access changes that have been made in past and automation can be built into JIRA once you’re further along in CI/CD practice. This sets up well for future integrations and progress in the overall practice of CI/CD.
I have seen JIRA integrated very well in this process and think it’s a good place to verify what was tested and completed in the past. You can utilize it as a troubleshooting tool to see who passed changes that may have broken something.
Testing
Good testing begins with viewing the app from a user’s perspective. What are the typical workflows? What features and steps do users go through often?
From this strong base of tests that make sure the workflows are working, you can go deeper and start unit testing.
Testing is the first step that needs to be taken. You need to get to a point where you can change almost any part of your system and be sure you didn’t break any other feature because your tests will catch those errors.
A testing check list could include:
- Check filter functionality
- Check tool-tips
- Check that important data points yield expected values
- Check that filters make sense for end users
- Understand if documentation is needed around the dashboard
Continuous Deployment (CD)
Once the peer review is completed in JIRA, the workbook would be switched from Development to Production. Due to the size of the team everyone should have access to Dev and Prod so there aren’t any bottlenecks in the process or extra work placed on an individual. When changes are needed (later down the road or in product enhancements), the workbook is moved back to Dev and the process is repeated.
Tableau Server naturally has version control which helps with Continuous Deployment strategies.
Immediate Goal:
Tableau Server Configuration:
- Sandbox: Sandbox will hold workbooks that are ad hoc and any that are exploration. We have an option to permission this to make as an individual user sandbox if wanting limited collaboration. Could then grant access to individuals to see specific workbooks that are in progress.
- Development (Dev): Dev is where we will bring workbooks that are going to be promoted to Production. When considering moving from Sandbox to dev you should think about if this will be moving to Production or not. If there is no intention to be sharing with others, then leave in sandbox and consider granting permissions to individuals to view.
- Production (Prod): Production is only to be used for business-critical reporting that will be viewed by either executive level individuals or potentially over 5 people.
Continuous Integration (CI)
Have one of your peers review the dashboard before promoting it from a Dev to Prod project in Server. The current idea is to put a testing task into your team JIRA board and a peer would move that task to mark it as complete. This also give a historical view of who is reviewing what, as well as slight version control for changes made. The JIRA task/ticket would include the modification made; this doesn’t have to be super in depth, but need enough information to jog the user’s memory.
JIRA Board Example:
The JIRA board would be broken out into 3 swim lanes. In Progress is either right before requesting testing or as you are working through your project. Once ready for peer review and testing the ticket, would be moved into UAT and assigned a tester. Here you can see I selected my coworker to be assigned to the ticket and he is notified. He would go through review and drag the task to Complete if all tests are passed. If issues are found, a comment is added and then moved back into the In Progress swim lane.
New Workbooks:
Throughout this process, I would either add changes that I have been making or add notes to the responses or concerns that came through peer testing via comments, depending on where we are in the cycle. These changes I am making would go in the New or Changes Made section of the ticket as comments.
My coworker would come then into the UAT swim lane, review the workbook, and check the functionality. For example, if there were tool tips are missing, this would be added to the comments to clarify the exact error, and the ticket is moved back to In Progress. Once concerns are addressed, the ticket is moved back into UAT and the verification process continues again until the tester deems the task to be correct and moves it to Complete The dashboard can then be moved to the Production project in Tableau.
With this process implemented there should be some major efficiency gains realized from the CI/CD pipeline. If the above processes are implemented there will be less user downtime, greater data confidence by the user, and even some light change tracking benefits. This is not the end-all or most typical form of CI/CD and there are ways to take the CI/CD journey further, but this is a great toe-dip into the world of CI/CD.
