Thursday, April 19, 2018

Continuous Integration, Delivery and Deployment driven by Git


I have it, I like it.

This is the simpliest idea that removes excecive "must remember" and "must do" workflows in the software development process.

Do you know Git Flow? This is all, your developers should know.

You use a convention that reflects your development, test and production evnvironments.
Say, you create Git-branches such as
  • dev
  • dev_stand
  • test
  • test_stand
  • uat_stand
  • prod_stand
Farther, you tune your automation to react appropriately to changes in such branches.
This is really easy in our days.

This can be
  • Project Buildings
  • Obfuscation
  • Static Code Analysis
  • Unit Testing
  • Packaging
  • Deploying
  • Data Updating from a production
  • Notifications
  • Integration Testing
  • Other dev systems integration, etc.



Thursday, March 29, 2018

Git Automated Conflict Solving

(draft, thoughts)

Every Git repository is a separate universe. I mean, even your local repository may be considered as a primary remote repository at any time.
So, how to merge two universes? By force, coercion and fire? Nope, USA is not applicable here, we always lose valuable pieces of work (world) in such a way.

CoG
Convention over Git approach is arising here.
First you agree to only sync branches under a naming convention.

You allow to push commits to your side repo freely and automatically until they do not conflict with yours.
If they conflict, another side is free to do, say, a Git-rebase and retry.
CoG deals with and separates notions of Non Fast Forward and Fast Forward commits of Git.
See CoG link, to take it deeper.

To recap, you are in an awkward position with your wishes, because this kind of things is uncommon in the Git world and is not researched well.

That's all. Have questions?

Monday, February 19, 2018

Pure Git with Convention over Git

It is an implementation of remote Git repositories synchronization by the pure Git and the Convention over Git.

This approach uses well-known Git tools, because Git has an innate ability to do such synchronizations.
All we need to add to Git is some convention.

(Consider to use git-sinc, the next generation of remote Git repositories synchronization.)

The situation

Say, we have teams in separate companies. Each team owns their own repository hosted on their own separate git server. This often happens for vendor-client scenarios.

The targets
  • Create a single force, a single team.
  • Eliminate severe and constant errors as a result of disunity.
  • Eliminate significant time wasting.
  • No single repository, no team's heart beating.
P.S.:
I even call this approach as Conventional Distributed Version Control System over Git.

Saturday, February 17, 2018

Approaches to synchronize remote Git repositories

Pure Git

Implementation: Pure Git with Convention over Git

It uses pure Git techniques.
This one is more academic but fully working.
Has some limitations.
Has the smallest amount of implementation dependencies.
*nix & Windows ready.

Stateless Analysis

Implementation: git-sync

The best approach. But it has more implementation dependencies: gawk, modern bash.
*nix & Windows ready.

Stateful Analysis

It depends on collected information about Git refs.
It has a wider set of conflict solving tools.
Predecessor of all other approaches.
Requires a modern software language, an IDE and good programming practices.

Implicit Renaming of Refs

My beloved.
Belongs to the Stateless Analysis.
It implies convenient manual conflict solving on the run.
It is kinda Git inside the Git with an additional degree of external references.

Friday, February 16, 2018

Glossary of synchronization of remote Git repositories

Convention-Over-Git
One of the approaches to automatically solve conflicts of synchronization between remote Git repositories.


fast-forward
safe, non-overwriting git fetch or push.

non-fast-forward
unsafe, forced & overwriting git fetch or push.

side
directly related one remote and many local git repositories. They are located on one side, i.e. in one company.

owner
owner of the side. A team that owns and uses their remote repository directly.

refs
git references, mostly such as branches and tags.

conventional refs
refs strictly separated by a convention and pertaining to different different sides. Each side owns its refs but can modify refs of another.

prefixed refs
This is a naming convention and an implementation of conventional refs by prefixes.
As an example:
"company1/some_feature", "company2-develop"
where the "company1/" and "company2-" are the conventional prefixes.

refspec
It specifies source and destination refs and can specify a non-fast-forward Git-fetch or -push by the plus "+" sign at the beginning.

synchronization interval
It is an interval between two synchronizations of remote Git repositories. Usually it is from one to three minutes.

reflog
Git Garbage Collector.

agentsync-agent
synchronization agent. Some implementation that doing all the work.