Posts by Nicola Paolucci
Hear Hear, the new Git 2.8.0 release is out! In the past couple of weeks, while the release candidate cycle was ongoing, I went through the commits and release notes trying the new things and scribbling down the interesting bits. To save you time here is a subjective selection of things to try out. Enjoy!
Professional teams that produce quality software often employ alightweight process to safeguard the introduction of new or updated code totheir stable branches. A code approval policy is an agreement within a singleteam or an entire organization to follow a set of rules regarding how and whencode is accepted into the main lines of a project, on the way to reach"production" and final distribution.
Recently I read about this amazing technique in an Hacker News
thread on people's solutions to
store their dotfiles. User
StreakyCobra showed his elegant
setup and ... It made so much
sense! I am in the process of switching my own system to the same technique.
The only pre-requisite is to install Git.
The Swarm is here. It is here to help us developers focus more about the relations between the components of our architecture and less about the physical machines and their IP addresses. If you need a refresher I spoke about and wrote an introduction to orchestration and the Docker tools: have a listen or read and come back because we are bringing this knowledge to the next level today.
After the fantastic DockerCon Europe and the recent releases of Docker
0.5.2 and Swarm
1.0.1 I finally have all the missing bits
to automatically deploy a suite of Atlassian products to a swarm cluster
Git is very good at merging code. Merges are local, fast, and flexible. Naturally every time one merges content from different branches conflicts can and will happen. Often solving a conflict is as simple as knowing and choosing the leading change. Sometimes resolving a conflict requires more work.
It's been a while since I have reviewed Git release notes but
that does not mean I haven't been eagerly reading more recent ones and
incorporating new gems in my routines. To celebrate my birthday (yay!) and the
recent release of Bitbucket Server I have collected a round of my favorite
features for the Git
2.x series (up to
2.6). Let me know if you end up
using any of these.
If you are a Go programmer you know how easy it is to whip up an application
that speaks HTTP. Go was born for the task. So it will come as no surprise that
it's possible to create an Atlassian Connect for HipChat add-on with less than two hundred
lines of commented code. What will this code accomplish? A new custom command
/test_hook, installable on any channel you are administrator of:
Let's add another arrow to our already full quiver of version control tools and techniques. Do you know that the Linux kernel you clone normally contains only a part of its entire history? If you need access to its uninterrupted evolution since the first commit you have to "graft" a few separate repositories together chronologically. In this post I'd like to show you how it works and why would you want to do that with your projects.
Recently I've been writing a service in Go to enhance the projects dashboard on Bitbucket - if you haven't heard we launched Atlassian Connect for Bitbucket as a way for anyone to build add-ons for three millions of Bitbucket users out there. Like many other Gophers I've been happily deploying my Go services using Docker. The process is smooth and pleasurable if not for one thing: the size of the official default Go image.
Follow along or just sit back and enjoy a live, hands on tutorial on the power routines of experienced git users. We'll explore with real world examples how to amend commits, do an interactive rebase - and why would you want to do one in the first place, how to solve conflicts without any merge tools, the power of less known merge strategies, how to do interactive commits, and much more.
This year I have been choosing Go for all my coding projects. Go is brilliantly fast, simple to pick up, it has a powerful concurrency model based on message passing, and no forced - always on - object orientation. My impressions are similar to the ones many have previously articulated well - for example see "Go is unapologetically flawed..." or the hilarious "Four Days of Go". Add to those a fair bit of gesticulation and enthusiastic jumping around and you get what I think.
Git subtree allows you to insert any repository as a sub-directory of another one. It is one of several ways Git projects can manage project dependencies. People with good memory will remember I wrote about the usage and the advantages of the command in an earlier piece on Git submodule alternatives.
Thanks to the flawless organisation of the GitHub team, Git Merge 2015 happened last week in Paris. It hosted the Git Core Contributor Summit on the first day, one day of Git talks and the celebration of Git's 10th anniversary on the second. I felt very humbled and fortunate to participate in the first day and to witness real discussions amongst the core contributors. Here's a few notes I took during the discussions of the core team.
Today I have an overview of the new developments in the Docker ecosystem. I'll explain briefly what Docker is and how it is evolving from a tool to package applications and easily distribute them to a set of tools to orchestrate and manage loosely or tightly coupled cloud solutions.
Even if it's still in early stages of development, Docker Machine is a very powerful tool, one of the three very intriguing new pieces of the Docker ecosystem - the other ones being compose and swarm. What does Docker machine do? It allows you to create and manage Docker hosts on local machines or cloud providers.
So here's the scenario: your team works independently on a Git repository but a part of the organization still uses Perforce to manage parts of the same code base. Those teams on Perforce are not planning to migrate but your team has already transitioned to Git (for lots of good reasons). It's important that you can keep a two-way code-sharing process ongoing between the code-bases so that improvements developed in either version can be shared, hopefully without costing too much time or bogging down your team too much.
I am always tweaking and tricking my bash environment. I hit the same issues again and again and I always have to look up the solution, time after time. This happens until I get annoyed enough to sit down - okay, generally I am already sitting down but you get the point - and create a custom function, put it in my .bashrc and deploy it to any machine I log on to.
Today, I want to tell you about the results of a hackathon, or as we call it a ShipIt project. It's fun for me to share and I hope you'll find it interesting. At Atlassian we have a big culture of innovation and experimentation. Every quarter, the company stops for 24 hours and employees can pick their own project to scratch their own itch: they form groups, sprint and spike working on new ideas. Sometimes we work on things completely off the wall, sometimes tiny improvements. Several key features included in our products (or even entirely new products) came out of these sprints of innovations.
In our recent Dev Den Office Hours we were asked some very interesting questions. One that caught my attention and on which I elaborated a bit on was the following:
When a piece of work is complete, tested and ready to be merged back into your main line of development, your team has some policy choices to make. What are your merge strategy options? In this article I'll explain the possibilities and then provide some notes on how we do it at Atlassian. Hopefully at the end you'll have the tools to decide what works best for your team.