This is the 7th part in the series of blog posts on managing the Azure DevOps using Terraform. You can find the series index here. Although this is the one of the part in the series, this can also be a completely independent post in itself. In this post, we’ll be using a Git repository to store the Terraform code files and discuss the best practices around it. This aligns with one of the practices in the Infrastructure as Code (IaC) framework and somewhat aligns with what is now a days known as GitOps framework. We’ll not go into details of if GitOps is suitable for Terraform or not into this post.Read More »
Category: Source Code Management
Version Control Practices for Managing Database Changes for Liquibase
In the last few posts on the managing database changes, we discussed how it is useful and what are the various benefits available. One of the core philosophies of the Database as a Source Code involves treating code for Database changes as source code. This is not limited to using a version control system like Git / Subversion / Mercury etc. but it also expands to other areas like designing the proper directory structure, making it scale ready for future changes, minimizing merge conflicts etc. In this blog post, we are going to discuss some of the practices used for organizing database changes when using Liquibase.
Read More »
Scale your Git workflow with Git hooks – 2
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.
Post-Checkout git hook
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.
Read More »
Scale your Git workflow with Git Hooks
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.
Read More »
Personalize Git Configuration for Better Productivity
In one of the previous posts at here, we discussed how we can use git aliases to improve the git experience. However, the personalization is not limited to setup of few command aliases. In this post, we’ll discuss how we can modify git configuration for better productivity and experience further. You will mostly need to do these changes per machine only once and they’ll stick around between upgrades. However, you can modify them later at any point, in case you want to.
Read More »
Checkout only selected Paths from Git Repository
In some organizations, its a common practice to put everything related to one project in one single git repository. Over the time, as the project goes on, more and more files keep getting added and it may reach a large size over the time. In such a case, you would like to check only a particular path, so that you can reduce the checkout time. It also make sense to checkout only selected paths, when you are running a continuous integration build, so that you can reduce overall build time. Even though git is very fast, but small improvements can really add up to be significant.
Read More »
Prevent the Continuous Integration build in Azure Pipelines after pushing commit
When configuring your Build Definitions on Azure Pipelines or on Azure DevOps server, you can configure a Continuous Integration (CI) build. A CI build runs for every checkin or commit that you make to source control. This allows you to start an automated process that for example compiles and deploys your build. This is a very useful process and it should be ideally setup in the above way. However there are times when you do not want the check-in to trigger a build at all. Read More »
Working with Tags in Git
To make proper git based workflows, one needs to learn both branching and tagging. While we have discussed git branches in depth in previous blog posts, we have avoided tags till now. Git tags are references that point to specific points in git history. Tagging is generally used to capture a point in the history that may be utilized in future to come back to. However, tags do not change from point, where they were created. So while branches move forward, tags do not. They represent static points in git history.
Some of the examples of tag might be like v0.1, v0.2 etc.Read More »