How to program with Liquibase XML files

I am used to DB programming with pure SQL files, but even if using an IDE, I am comfortable in seeing SQL commands like so as I can sit down with my developers and troubleshoot problems we encounter

create or replace function register_user (
    p_email                email_type,
    p_username             username_type,
    p_plain_text_password  plain_text_password_type
)
returns token_type
as $$
declare
    certificate token_type;
begin
    insert into user_account
    (
        email,
        username,
        encrypted_password
    )
    values
    (
        lower (p_email),
        lower (p_username),
        crypt (p_plain_text_password, gen_salt('bf'))
    );

    select into
        certificate get_user_account_activation_certificate (p_email := lower (p_email));

    return certificate;
end
$$ language 'plpgsql';

My devops team wants us to use a DB migration tool like Liquibase to help with automated deployments but Liquibase manages changes to the DB in XML like so (copied from here). This is completely foreign to me. Imagine if GitHub demanded that you only write the changes to your code and then apply those changes incrementally

<?xml version="1.0" encoding="UTF-8"?>   
<databaseChangeLog   
  xmlns="http://www.liquibase.org/xml/ns/dbchangelog"   
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"   
  xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog
                      http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-3.8.xsd">   
  <changeSet  author="authorName"  id="changelog-1.0">  
    <createTable  tableName="TablesAndTables">  
      <column  name="COLUMN1"  type="TEXT">  
        <constraints  nullable="true"  primaryKey="false"  unique="false"/>  
      </column>  
    </createTable>  
  </changeSet>  
</databaseChangeLog> 

To me, that XML approach is completely unacceptable and all my DB developers will resign if I force them to code like that. What are some better approaches to using Liquibase without completely blocking progress.

• Should I put the functions/procedures inside some sql file? (as suggested here)
• Should I apply the changes incrementally (eg. create a blank function, then define its return value, then its parameters...)?
• Should we program the database alongside the migrations then convert the changes to XML and use that instead?
• Is there some GUI for Liquibase that will better manage these XML files?

Liquibase does not require that you use XML. It works great with SQL too. You have a few options in how you structure things that are illustrated in the blogpost and the Liquibase documentation links below.

https://www.liquibase.org/blog/plain-sql

https://docs.liquibase.com/concepts/basic/sql-format.html