How to deploy a junior programmer

Question

I just hired a junior programmer and he will be 2nd real programmer next to me.

Our software is structured in git with the gitflow workflow. I normally develop and push straight on the development branch.

When a commit is pushed it is directly picked up by TeamCity and Octopus and deployed on the test server under the dev.domain.com domain.

This way the QA guys can test my changes.

Now the junior guy won't have this luxury, he will need to make PR's to get on the development branch. He still needs to be able to push work to a test environment for QA to look at.

So far I have come up with 2 soltions:

1: Create a single branch where he commits to, will automatically deploy to a dev2.domain.com site. Problem is that PR's are hard to do as he will continue to develop new code in this branch.

2: For every new feature have a script create automatically a TeamCity + Octopus configuration, deploy to a feature.domain.com site and tear it down again when the feature is merged. Advantage is that it's very easy to PR's because features are contained, downside is that you need to setup the test environment and it takes time + server resources.

How do other teams manage this workflow?

Edit: it looks like the point is not coming across. My code goes through the exact same steps as anyone elses code. But the question was how do I structure the test environment? If I make feature branches how do my manager and QA access them? Do I have to manually set them up in TeamCity and Octopus? That's why I push on develop, it gets deployed to our test environment that way.

Answer 1

I normally develop and push straight on the development branch.

With all due respect, this is a problem. Nobody should be pushing directly onto develop, certainly not if you're using gitflow - everything should go onto a feature branch and then be merged onto develop once the feature is complete. What do you do if you're half way through developing a feature and priorities change so a different feature now needs to be completed first?

Also, now you have another developer working on the project, you should get your code reviewed as well and you can't do that if you're going directly to develop.

How do other teams manage this workflow?

At some point along the line, you need to be testing develop (or another branch which contains your candidate releases) - otherwise you won't spot any interactions between your features.

If you also have resources to perform some checks on individual branches before they get merged to develop, that's great, do that, but these should normally be quick checks on the changes for that feature rather than full regression type tests.

Answer 2

To add to @Philip's excellent answer I think you also have to look at this from a human point of view.

If you stratify your working practices then you are denigrating your Junior Developer's skills. Sure its good to have quality gateways; but they should apply equally to everyone if you want to promote teamwork and self organisation.

My feeling is that this is more about you holding onto the code rather than setting up good practice. Ask yourself, If you employed a developer with more experience than yourself, would you be happy having them review and approve all your code?

Answer 3

As @Philip already pointed out, ideally you shouln't have been working directly on the development branch either in the first place.

This answer to me nicely summarizes why using feature branches, even on a small or 1 person team, is a good idea.

---

I'd suggest setting up 'personal' dev spaces for you and the new developer (and for each future new developer as well obviously), where you can work on your feature in a separate branch, once it's done, set up a pull request (which is both a nice point on ingress for automated tests, and also an opportunity to show your work to the junior dev/have a look at his work) and once the tests pass, process the PR and put the feature on the development branch so the QA team can check it out and do their thing.

These personal dev spaces can be locally, using docker/vagrant, a a seperate server, ... That is a matter of preference.

The advantage of this approach is future-proofing your workflow. You're putting in place a system where the amount of developers working on a project does not change the workflow. They all got their own dev environment, work on a feature and create a PR which will eventually get to the development branch to be processed by QA.

This way the QA team still has only 1 point to look at, reducing complexity on their part (as there is no need to keep track of separate urls for separate features/devs).