Month: November 2017

Posted on

Git workflows

Confused about how to work with Git? You soon will not be confused, it is a well designed and versatile essential tool for remote development.

1. Comparing workflows

2. Gitflow architecture (also covered in article 1.)

Remote Development uses the Gitflow branching model. Simply put:

0. Initial steps
git init
git remote add origin git@softwareantelope.com/project-repo.git
git fetch

1. Developer checks out Master branch
git checkout master

2. Developer checks out a new feature branch
git checkout -b feature/my-new-feature

3. Developer work on and commits to feature branch

4. Developer pushes the feature branch to origin

First time:
git push -u origin feature/my-new-feature

Subsequently:
git push

5. Developer issues a pull request for the feature branch into Master

Simple?

The admin maintains the git repository, and collects ssh-keys (public) from each developer so that they can login to git@softwareantelope.com without a password.

The git admin checks the new feature branch, and notes any migrations that are required. When the PR is approved it is merged into the staging branch. Developers can now check their branches have been correctly merged into the staging branch and flags the branch as releasable if it does not cause issues.

At the end of the sprint, the admin builds a new server instance for live and switches to it after applying any updates. The staging branch is now merged with the Master branch. Developers can continue to work in their feature branches by merging master into their branch on the new sprint.

ANY FAILURE along the way is immediately notified to the admin so it can be fixed before it becomes a major exercise. Remember keep your branch atomic and up to date with the latest master.

Conflicts

Provided that developers work on separate concerns conflicts are kept to a minimum. Conflicts are resolved by the Admin using the simple “important branches first” principle.

Solo Developers

These rules apply to teams. They are also adhered to for developers who are single-handed on a project. It allows control, accountability, backup and many other advantages.

Posted on

Advantages for Clients and Agencies

There is great future for Remote Development. We understand there must be advantages for clients: less cost, more work, more accountability, less investment. More time. Less expense.

Agencies can get in on the ground floor of what is obviously the future. We can defeat the evils of a lack of talented developers in the market and the solve the problem addressed by IR35 (an independent business being treated as an employee).

Remote Developers are more able to deliver to budget for an entire project than onsite teams. Staff expenses can be avoided for project work, reducing risk and time to market.

As well as a competitive daily rate, RemoteDevelopment.co.uk invoices at the end of each Sprint. Of course only tested deliverables are included, with Sprint planning for the next Sprint.

Professional pride is at stake – each two-week sprint must deliver results.

A costed budget for an MVP (minimum viable product) is more likely to achieve working software fast. Accurate quoting for an Agile project is not the issue. Working within budget and delivering useful results is the issue.

An expectation of evolution during the journey may mean extra Sprints are required.

Predictable cost. Rapid results that are tested on a Staging Server and Test Driven Development are all parts of a new way to get your software goals achieved within budget.

Posted on

Motivations and Rewards

Am I the right developer for your project? How can you tell?

As a contract developer, the first question a client asks me is “what is your rate?” If I am the only person available with the skills, my rate should be different than if I am competing for a job. It is like asking “how hungry are you?”

There is a problem with knowing the cost of everything and the value of nothing: how do you know in advance what something should cost? Oh, “The market set the price”, I hear you say. “The market is king!” Really? Do you want to motivate developers toward technical excellence?

A “rate” is not necessarily a “quality differentiator”. One technology could get the job done in one day, another may take a week. Which do you want to pay for? You simply want to buy experience.

Developers may have financial motivations, sure. But is that the primary motivation? Is technical progress not a more powerful motivation? Every developer I have worked with is motivated by technical advances and invention.

Invention. That is what we look for in a developer – have you invented anything? Remote Developers do not need a “rate” – they work to achieve your business goals, take pride in progress and charge a fair fee against a budget. Why? Because we are inventors, not employees. A budget is simply a scope. A scope will creep and efforts to stop clients changing their mind are simply futile.

If you want to create a Minimum Viable Product (MVP) to test your idea on the web, you will want us to work to your budget. You want us to be motivated to get results. To develop using the latest and greatest software methods.

Your budget gives us a scope to explore new technologies or to simply employ what we tried already. Innovation may cost more. Or it may result in a better product that works for you.

It comes down to communication.

You may need to review your budget when your MVP needs to be extended to create a working business proposition.

We believe it is best to mark progress and provide clients with technical proficiency. A budget simply provides predictability