This blog post outline the pros and cons of the Git workflows propagated by well known software engineering platforms.
Each of those platforms recommend their own Git workflow or Git branching philosophy.
Remember: Branching is the core concept of Git. But you can use this feature in different ways.

This blog post shall give you a short overview about the different Workflows and their pros and cons.

Different Workflows

Gitflow

Vincent Driessens post was one of the earliest description of a workflow model. He describes the idea and the actions required very well.
The model suggest to use two “main” branches: master and develop. The master branch is the Git default branch. And in this workflow the branch is used to tag releases.
The develop branch is where feature and release development takes place. This leads to additional effort for merging. You need to merge “hot fixes” and “release branches” in to two other branches: master and develop.
Furthermore most git tools consider the master branch as the default branch and are configured accordingly.

GitHub

The GitHub Flow is a lightweight, simple workflow. This provides many degrees of freedom how to work with it. On the other hand this requires to clearly decide in a collaborative project from which branch you want to release.
Forking is branching on project level, kind of and popular on GitHub. But this is a different story.

GitLab

GitLab propagates two workflow models: Environment and Release branches.
The Environment workflow is useful for DevOps as well as other features (e.g. Docker Container Registry) of GitLab.
The Release workflow is based on the upstream first policy to avoid version fragmentation. But you have to spend time on cherry-pinking bug-fixing patches into different releases.

Bitbucket (Atlassian)

Bitbucket supports various workflows from above. Those are the Centralized, the Feature Branch, the Gitflow and the Fork Workflow.

VSTS

The Microsoft recommendation is also to use branches. But for long running branches they recommend using feature flags/toggles and don’t recommend Tags for releases. Using feature flags require disciplined work and following known best practices to keep your project tidy.
Not using tags increase the effort required to keep your release branches updates with latest features and bugfixes. Using tags for releases in a specific branch would be less effort.

Others

Git documentation describes some workflow models as well. One of those models (Dictator and Lieutenants Workflow) is well established in the Linux Kernel development.

Conclusion

Don’t go with the Git Flow!
A Git workflow is a powerful tool to arrange the way you work in your project. Think, chose and adapt the “best” workflow for the needs of your project and organisation.
Be aware if your workflow becomes a mess, mostly your project and/or organisation is a mess as well.
Choosing a workflow for your needs is the beginning of your journey with Git. Best practices (Rebase, Merge/Pull Requests, ..) for your journey will follow…

This post appeared first on my personal blog.

Migrating to Office 365 can be quite a struggle but it doesn’t have to be like that. With this blog entry I hope that you can avoid some critical mistakes that I have done during the migration.

There are several ways how you can migrate your Exchange Environment to Exchange Online/Office 365. We will focus on the cutover migration and will also cover some things about the synchronization product Azure AD Connect.

A lot of information about the process can be found in the official guide, which I urge you to read first.

Before you start the migration, consider the following things:

• Hidden mailboxes, contacts or distribution groups won’t be detected by the migration endpoint. This is also a good way to exclude mailboxes from the migration if you don’t want to move them to the new cloud. You can get hidden mailboxes with the following command:
  
  on your local Exchange Server

  get-mailbox * | where {$_.HiddenfromAddresslistsenabled-eq"true"} | ft Name, PrimarySmtpAdress

  1	get-mailbox * | where {$_.HiddenfromAddresslistsenabled-eq"true"} | ft Name, PrimarySmtpAdress

• Any mail forwarding settings will not be migrated. Before you complete the migration batch, you should filter out all the mailboxes or distribution groups and write them down. You can use this command as an example:
  
  on your local Exchange Server

  get-mailbox * | where {$_.ForwardingAddress -ne $null} | FT Name, ForwardingAddress –autosize

  1	get-mailbox * | where {$_.ForwardingAddress -ne $null} | FT Name, ForwardingAddress –autosize

• Public folders are not included in the cutover migration. However, there are guides for Exchange 2007 or 2010. Exchange 2013 & 2016 public folders right now are not officially supported. In this case I would advise you to export the folder manually and import them into Exchange Online – be aware that you will lose permissions and mail enabled public folders this way.

• Things like mailflow rules, connectors & mailfilter settings will not be migrated and should be done before you start the migration

Azure AD Connect:

After completing the migration batch, you might want to set up the AD Connect Synchronization Service. You can’t do this before, because this will interfere with the Cutover Migration to Office 365. AD Connect will map all on premise users with the completed migration batch, so you don’t have to worry about any duplicates. The objectGUID will be used by default as the source anchor. Since this attribute is unique and immutable (if you are not changing AD forests) I would not change this setting unless you know what you are doing.

When configuring the AD connect, you can choose the object types, attributes, organizational units and if you want enable password hash synchronization, so users can use the same credentials on the cloud as on premise.

• To prevent accidental deletion of all accounts with the synchronization service, you should set a threshold. I disabled all mailboxes after I completed the migration batch and found out too late that not only the mailbox but also the AD user got deleted. It has cost me a lot of time recovering those accounts.
  
  on your local AD Server

  Enable-ADSyncExportDeletionThreshold -DeletionThreshold 10

  1	Enable-ADSyncExportDeletionThreshold -DeletionThreshold 10

• To see and change the schedule for the sync, use the following command
  
  on your local AD Server

  Get-ADSyncScheduler # For a 30 minute interval Set-ADSyncScheduler –CustomizedSyncCycleInterval 00:30:00

  1 2 3 4 5

  Get-ADSyncScheduler   # For a 30 minute interval   Set-ADSyncScheduler –CustomizedSyncCycleInterval 00:30:00

• If you can’t wait for the next SyncCycle to run you can always start it manually
  
  on your local AD Server

  Start-ADSyncSyncCycle –Policytype delta

  1	Start-ADSyncSyncCycle –Policytype delta

There is also a tool called “Synchronization Service Manager”, which will be installed when you set up AD Connect. This tool helps you to overview the whole synchronization process – you can check what items and what attributes have been created, modified or deleted. Basic actions like a synchronization cycle can be started as well.

For more information about the default configuration of AD Connect check the following site.

Assigning Licenses to Mailboxes:

After you migrated the mailboxes to Office 365, you need to assign user licenses to these accounts or they will not be able to sign in into Exchange after a grace period of 30 days. If you have mailboxes which are not for personal usage, you can convert them into shared mailboxes either with the Office 365 Administration Portal or Powershell. Here is a guide how you can connect to Exchange Online with Powershell and import.

To find out what licenses are available use the following command:

Here is an example how to assign a license to all user-mailboxes:

If you want to convert mailboxes to shared mailboxes make sure that the property “LicenseReconciliationNeeded” is set to false after the conversion. Otherwise your shared mailbox might be deleted after 30 days. If it is set to true, you must convert the mailbox back to a usermailbox and assign a license temporary. During the conversion back to a shared mailbox, the license will be unassigned automatically and the property will be set to false.

I hope I saved you some trouble with this post and I wish you a smooth migration to Office 365.