Skip to main content
Announcements
Global Transformation Awards! Applications are now open. Submit Entry
Ouadie
Employee
Employee

On a previous blog post, I shared a nifty tool that helps you introduce version control into your development workflow. I invite you to read about that and follow the gitoqlok and its latest updates.

In this post we are going to talk about a simpler, less cumbersome way to implement a simple version control system using Qlik Application Automation and the Github connector blocks. So, if you are someone who ends up with dozens of apps named v1, v2, v3, etc... then we're about to end that.

Screenshot 2024-03-29 063701.png

 

The setup is pretty simple, a Qlik Application Automation, a Github account, and we connect the two!

Let's start with with creating the Qlik Application Automation on your Qlik Cloud tenant. Head over to the Add New, then create a new Blank automation,

Screenshot 2024-03-29 062658.png

 

Once created,  you'll be able to configure the Start block. Here, we are offered different ways to kick off the automation and in our case, we will use the WebHook run mode in order to hook into the Qlik Cloud Services.

We would like to run the automation once an App is published in our managed space. Take a look at the image below and change it to suit your needs.

Screenshot 2024-03-29 063857.png

 

Our next block is the Get Space block, you will find it under the Qlik Cloud Services section. This will allow us to find our "Git Demo Published" space and grab its ID. This is easy to do using the Do Lookup function.

Screenshot 2024-03-29 064348.png


Since Github doesn't allow space characters in Repository names, we will mitigate that by creating a variable which we will use to format the Space name into "git-demo-published". Notice on the image below that we use the Replace and Lowercase text functions.

Screenshot 2024-03-29 083318.png


Great, we now have our space information. Next, let's use the Get App Information block to grab the published app's id as shown below.

Screenshot 2024-03-29 084138.png


Our next step is to actually Export the App (think of this as right clicking on the app in the hub and exporting it). 

Screenshot 2024-03-29 084326.png

Alright, we now have a nicely formatted space name that will be used as our Repository name, and we have our "published" app exported and ready to go.

Our final step is to connect to Github. Qlik Application Automation makes this easy, just grab the Get Repository block under the Github section and drop it in. You will need to first authorize Qlik, so do this under the connection tab.
 
Screenshot 2024-03-29 085247.png

In the Inputs tab, enter your username and drop in the Variable we previously created as the name of the Repo.
Under Settings, make sure to change the On Error dropdown to "Ignore - Continue Automation and ignore errors". This will allow us to bypass a limitation set by Github for when a Repository is not yet created.

Screenshot 2024-03-29 100833.pngScreenshot 2024-03-29 100853.png

Next, using the convenient Condition Block, we will check to see if the returned value from the Get Repository block is empty (i.e, there is No repository under that name). If YES, we create it using the Add Repository block

Screenshot 2024-03-29 193134.png

Screenshot 2024-03-29 101305.png

After the condition is met (or if we already have the existing repo), we can now push our App to github.
We will use the Create of Update File content Block to push the App qvf into the main branch. Take a look at the screenshot below to review the settings. Notice that we used the App name from the previous Get App Information block and appended it with the .qvf extension.

Screenshot 2024-03-29 102359.png

We're all done with the Automation. You can save it now and head over to your App to publish it and test.

Screenshot 2024-03-29 102927.png

Publishing the app will trigger the automation to run, and if we now head over to Github, we can see that a new Repository names "git-demo-published" (our formatted Space name) has been created, and a new commit was added with our first version of the App as a qvf.

 

9d9611af-e7c3-4a3f-a4f5-0413742023af.png

After publishing a second time, we notice a new commit with the second version of the App.
Screenshot 2024-03-29 103252.png

By using this workflow, we can guarantee that our app versions are automatically stored for us to got back to if needed or to collaborate with other team members in a more efficient way.

I hope you found this blog post helpful, let me know if the comments below if you have any questions!

Ouadie

4 Comments
edwin
Master II
Master II

Hi

looks great. Is this available to enterprise versions?

thanks for the info

edwin

1,044 Views
felix_r
Contributor
Contributor

Great insights shared in the blog post about automating app uploads. I see how the method outlined could streamline deployments significantly, especially for apps with minimal data requirements. However, I'm curious about scenarios involving larger applications, particularly those running into a couple of hundred megabytes or more.

1,017 Views
CJ_Bauder
Partner - Contributor III
Partner - Contributor III

@Ouadie amazing post - exciting to see a simple UI version of VC for use in Cloud.

@felix_r makes a good point - ideally we'd add a step to purge data from the app to emulate "Export without Data" so no content is included. Lastly - does it make a diff if you store the Shared vs. the Managed space app in terms of rollback publication? Want to ensure all IDs and content is rolled back properly in both cases with how space publication operates.

EDIT - One afterthought - this could also be implemented easily for script files as well - making for top tier devops processes.

Awesome work!

 

 

912 Views
KryptoNox
Contributor
Contributor

@Ouadie Is it best practice to have separate automations like this one for each managed space?

0 Likes
459 Views