3

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.

  • 5
    Why shouldn't the Junior's changes also be merged into the development after the developer finishes a task and QA member will simply test the Junior's changes along with everything else? – Andy Jun 20 '18 at 5:53
  • 1
    Even easier. Why shouldn't the Junior has a feature branch and send a Merge Request to develop (if you deem it necessary)? If you don't take advantages of the methodology and tool you say to follow/use, what's the point of implementing them? – Laiv Jun 20 '18 at 7:54
  • 2
    Pair program with him. He'll learn faster, you'll have the advantage of a second pair of eyes looking at what you do and you avoid all the issues around workflows that you describe. – David Arno Jun 20 '18 at 8:53
  • With respect to your edit: "My code goes through the exact same steps as anyone elses code." vs "I normally develop and push straight on the development branch." and "Now the junior guy won't have this luxury, he will need to make PR's to get on the development branch." I hope you can see why people are confused. – Philip Kendall Jun 25 '18 at 7:26
24

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.

  • 11
    Agreed, having your junior review your code not only helps pick up your misakes but helps them learn and feel part of the team – Liath Jun 20 '18 at 9:16
  • I agree with your statement, except I don't have a good answer of how to test those features then. Our process is development -> review approval -> QA. So I build it, it gets pushed to the dev-test site, manager reviews the feature, QA tests it for bugs. This is a good process for our line of work. It is true that multiple features trouble the water. – Farlock85 Jun 20 '18 at 13:16
  • 3
    everything should go onto a feature branch and then be merged onto develop once the feature is complete -- Always explain why when you make assertions like this. Too many people simply state "you're doing it wrong" without providing some reasonable justification. – Robert Harvey Jun 21 '18 at 14:44
6

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?

  • 1
    I think the question is completely missed here. 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. – Farlock85 Jun 21 '18 at 14:10
  • 4
    what about "Now the junior guy won't have this luxury, he will need to make PR's to get on the development branch."? – Ewan Jun 21 '18 at 14:36
  • So do will he spin up a new test environment for each feature? Or push on a single feature branch? – Farlock85 Jun 21 '18 at 15:46
  • 1
    @YesMan85 I'm trying to avoid the technical side as I think PhilipKendall has already covered that. But the normal way would be for everyone to work in features and test develop. Testing feature branches is also done, but in a small team it seems a bit overkill to me – Ewan Jun 21 '18 at 15:52
  • 2
    both ways have merit. the point is to pick one. not have one for you and one for others – Ewan Jun 21 '18 at 16:44
1

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).

  • After some more pondering I think this is what we will do. The reason I didn't want to do this was that I didn't want to have an endless stream of bug fixes PR's for new features, but that's a different issue... I'll make sure that at the end of each sprint it's all merged and tested so we have a potential releasable product. – Farlock85 Jun 25 '18 at 14:26

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.