Sometimes it happens that for the organization and maintenance purpose, you would like to keep all code related to one component of a product in one place only. Now that component may be complex component having multiple sub parts like API, UI, Database etc. Again, for the purpose of easy maintenance, you would like it all under one repository, which is not an bad idea. Now, imagine if you have different builds configured for different sub-components which are using this source code as their base and are configured to trigger on some event, say commit. Then for each small and big commit, it will trigger build in each of the configured builds. Ideally, if the change was related to only one sub-component say API, then you would need to trigger only API specific build and not the ones for the UI and/or Database. Continue reading “Using Path filters in Build definition in Azure DevOps / VSTS”
After making some changes to the build definition of one of the dotnet core repositories, we started observing this error with the SonarQube tasks inside the build definition in VSTS:
When we checked the complete logs, we observed below issue:
In git workflow, the ideal strategy to work is to fork a new branch, make changes and finally merge in the main development branches. Over the time, this results in creation of large number of branches which are not required and becomes stale. Although a branch is just a pointer to an commit and does not require more than 40 bytes of disk space, it can be painful to search a long list of branches and deciding what you want to work on. Also since we humans are not good with creating unique names for branches, they can also result in confusion.
Below are some steps to clean branches from git repository to remove the clutter.
Delete a Local branch
Git Cherry-pick is used by many Organizations as an alternative to the rebase and merge. Cherry-pick is used to copy selective commits from one branch to another branch. Unlike a merge or rebase, cherry-pick only brings the changes from the commits you select, instead of all the changes in a branch. You can also choose whether to apply only one commit from another branch or a number of commits from another branch.
Why Git Cherry-pick
Cherry-pick is a great way to tackle below common problems:
- Accidentally committing on the wrong branch. In this case, one can use git Cherry-pick to apply the change(s) over to the correct branch and then reset the original branch to the previous commit. Continue reading “Understanding Git Cherry-pick and how it is useful”
Garbage collection is a well known software practice. The garbage collector, or just collector, attempts to reclaim garbage, or memory occupied by objects that are no longer in use by the program. When we talk about the Git Garbage Collection, we mean almost the same thing. Git garbage collector runs a number of housekeeping tasks within the current repository, such as compressing file revisions (to reduce disk space and increase performance), removing unreachable objects which may have been created from prior invocations of git add, packing refs, pruning reflog or stale working trees.
Continue reading “Understanding Git Garbage Collection”
Docker files are used to create docker images. When you are building image using Dockerfile, by default it would search for a file named Dockerfile with no file extension in the current directory context. Now normally an application have multiple environments like Dev, QA, Production etc. Few things like application settings and environmental variables will generally differ from one environment to another environment. To account for these changes and for image to work properly in these different environments, it needs to be either generic in nature (which is a very rare case and puts lots of un-necessary modification in the application code itself to account for these changes at runtime) or images needs to built for each environment separately.
Continue reading “Dockerfile Naming Convention and Organization”
Part of the source code management is to be able to quickly determine the difference between your branch and the main development branch. Usually this happens to be the master but this can quickly change if you are following feature based development or trunk based development. VSTS has the concept of the compare branch where it would provide the number of commits ahead or behind data for all other branches. This helps one in quickly determining the related information by just taking a glance at the branch page.
To set a different branch as the compare branch, select the branch in the reference and click on the three dot icon: