Enabling product teams to achieve their full potential
In our previous post, we discussed what are git hooks, how to install git hooks ,few of the local git hooks and custom hooks. This post is continuation of the same and we are going to discuss more types of git hooks and their customization.
The post-checkout hook works a lot like the post-commit hook, but it is called whenever you successfully check out a reference with git checkout.
Continue reading “Scale your Git workflow with Git hooks – 2”
Git hooks are a very useful feature in the git. Git hooks are scripts that you can place in a hooks directory. They are triggered every time an specific event occurs in a Git repository. They let you customize Git’s internal behavior and trigger customizable actions at key points in your CI/CD and git workflow.
Some of the common use cases include to encourage a commit policy, altering the project environment depending on the state of the repository, to trigger continuous integration workflows before and after commits, etc. However since scripts can be written as per the requirements at hand, you can use Git hooks to automate or optimize virtually any aspect of your development workflow.
Continue reading “Scale your Git workflow with Git Hooks”
In our previous blog post, we describe how we can conditionally prepare for database state to determine certain conditions and then only proceed to deploy our changes. This prevents us from doing errors like inserting the same record again or dropping a table full of records. However, irrespective of our precautionary measures, mistakes are bound to happen. So we need to prepare for those eventualities as well. This may also be needed if you roll out certain changes and found that those changes were inadequate to resolve the matter at hand. In liquibase, we can prepare for these kind of scenarios using the concept of rollback and tags.
Continue reading “Prepare failback strategy for database changes with Liquibase”
In our previous blog post, we discussed how we can apply different changelogs to different database environments. It is more than often, that when applying a changelog, changeset writer assumes database in a certain state. Like when you are adding a column to the database, you would assume that corresponding table is present. Or when you are dropping a table, it has no data in it. Or we assume that underlying database connection is of a particular nature. We can check for and decide what to do by using the concept of Preconditions in the Liquibase. Using preconditions allows to validate underlying assumption and decide the course of action. Continue reading “Check database state and conditionally apply changes in the Liquibase”
In our previous post, we learned how to use Liquibase to export and compare databases. That brings us to another important question: how do we deploy separate changes on separate database environments like dev, qa, prod etc. Often times, developers would want to push certain changes in the dev environment more frequently and often and not all of them necessarily make it into the production. For example, dev database may have a special ERRORLOG table which stores the debugging information, but there is no requirement of that in the QA or production environment. Similarly, QA team would like to insert some data and modify certain values Continue reading “Selectively apply Changes to Database Environments using Liquibase”
