Wastholm.com

The list below contains all the tricks and tips I had to research and integrate in my workflow to keep using Git joyfully in conjunction with SVN. Enjoy!

The first obstacle we reached when we were setting up our continuous delivery pipeline was figuring out which branch to continuously deliver. We changed our minds a few times before settling on a pipeline that would run all the code from the development branch. Except production, that is, which would deploy from master. This was always a bit confusing and didn't make a whole lot of sense. The idea with git flow is that master always represents production while develop represents the current state of development. The idea of continuous delivery, though, is to reduce the time between what master represents and what develop represents. In the ideal case, develop and master would converge. These worldviews clash quite spectacularly when tried to use in conjunction.

In this post I present the development model that I’ve introduced for all of my projects (both at work and private) about a year ago, and which has turned out to be very successful. I’ve been meaning to write about it for a while now, but I’ve never really found the time to do so thoroughly, until now. I won’t talk about any of the projects’ details, merely about the branching strategy and release management.

If you’re fighting Git’s defaults, ask why.

Treat public history as immutable, atomic, and easy to follow. Treat private history as disposable and malleable.

The intended workflow is:

1. Create a private branch off a public branch. 2. Regularly commit your work to this private branch. 3. Once your code is perfect, clean up its history. 4. Merge the cleaned-up branch back into the public branch.

In Git, there are two main ways to integrate changes from one branch into another: the merge and the rebase. In this section you’ll learn what rebasing is, how to do it, why it’s a pretty amazing tool, and in what cases you won’t want to use it.

SVN Access Manager is a powerful tool for managing access to subversion repositories. The tool provides user and group management and access rights (read /write) to dedicated paths in a repository as well.

SVN Access Manager uses projects to give users the rights to manage their own modules in a repository. Project is used substitutionary for a toplevel directory.

The basic idea of story branching (sometimes referred to as “issue-driven development”) is that you create a development branch for each and every JIRA issue you implement.

Bug fixes, user stories, spikes… they all get their own branch.

Madness, you say!

And I would agree with you if we were still using a centralized version control system like SVN.

But branching in Git is very lightweight and merges don’t lock up the entire repository, making this crazy idea quite practical.

Many development teams are used to making heavy use of branches in version control. Distributed version control systems make this even more convenient. Thus one of the more controversial statements in Continuous Delivery is that you can’t do continuous integration and use branches. By definition, if you have code sitting on a branch, it isn’t integrated. One common case when it seems obvious to use branches in version control is when making a large-scale change to your application. However there is an alternative to using branches: a technique called branch by abstraction.

If you are familiar with vcs software such as Subversion, you might think of boar as "version control for large binary files". But keep reading, because there is more to it.

Boar stores snapshots of directory trees in a local or remote repository and provides tools to ensure that your data is consistent and complete. You can keep just some or all of your data checked out for viewing and editing.

The repository has a simple layout to ensure that the data can easily be extracted even if the original software should be unavailable. This simplicity makes boar ideal for data that needs safe long-term storage.

You never develop code without version control, why do you develop your database without it?

LiquiBase is an open source (LGPL), database-independent library for tracking, managing and applying database changes. It is built on a simple premise: All database changes are stored in a human readable yet trackable form and checked into source control.

|< First   < Previous   21–30 (41)   Next >   Last >|