using gitflow

[Jignesh Patel]

is there any suggestions about using gitflow for the larger project?

[Liutauras Vilda]

Not sure what kind of suggestion you are looking for, that may depend on multiple factors, however, I don't think project size matters most here, at least not anymore.

I/our team tried multiple approaches over the course of multiple projects in time, and what we found, so called trunk-based works best for us. But that's for us, influenced by multiple factors. Such factors could be a framework(s) used (that allow fairly easily to hide features behind the feature flags), type of project working on, maturity of CI/CD process and other.

I see the use of Gitflow as well if it is used with the mindset that was envisioned for such development process, but I also see it could be used inappropriately, which would be more similar to trunk-based in its effect, just with an extra overhead of maintaining extra complexity. I also see it, if not used with care, that may end up in often merge conflicts that may more annoy and be prone to extra bugs than do anything good.

So it is not easy to answer

But if you/your team have less experience with version control in general, I'd suggest to start with trunk-based and see how it goes. Don't see a problem to move to other ways if there would be such need at some point later.

[Tim Holloway]

I wouldn't keep a parallel branch gratuitously. I can see running multiple trunks if you are a commercial developer and you have to support multiple versions at the same time. For example, if you're Oracle and you have different clients running different versions of MySQL and you need to keep the older versions backported for security issues and so forth.

But I'm not sure that that can be called Gitflow, strictly speaking.

[Jignesh Patel]

Thanks, Tim and Liutauras.
Our team is not new to version control, and most of the coding will use microservice concepts, probably using fast APIs and an Amazon Web Services network. In that context, continuing a feature-based or GitHub Flow seems more appropriate. That also fits better for TDD.

So, switching gears, in the feature-based, what is a more appropriate approach, CI/CD checks putting at the pull request or every push in a remote feature branch?  Github advised me to do this at the time of the pull request, but I did work on a project where CI/CD was integrated at every push for each feature. Which approach fits for TDD?

[Liutauras Vilda]

Jignesh Patel wrote:... what is a more appropriate approach, CI/CD checks putting at the pull request or every push in a remote feature branch

Based on the team needs. What mostly make sense to me, is WHEN pull request is opened, to build/test every commit, that way you can have guards and ensure, that such pull requests couldn't be even merged to a main branch if they don't pass build.

You mention TDD in your post, but it is not related to any of those, neither it is more appropriate in combination with GitHub Flow or CI/CD or so... That's totally different thing. TDD in my head is a software design framework. For some people, TDD is write tests first, then code later, which it is, but the goals are very different from being a design framework I mentioned.

I don't practice TDD myself, shame on me. But I never stop dreaming about it, because I think I get it. Maybe one day

[Tim Holloway]

Liutauras Vilda wrote:TDD in my head is a software design framework. For some people, TDD is write tests first, then code later, which it is, but the goals are very different from being a design framework I mentioned.

I don't practice TDD myself, shame on me. But I never stop dreaming about it, because I think I get it. Maybe one day

I would rather call TDD a design philosophy. JUnit is a framework, but hardly the only one for TDD.

Personally, I'm more into Literate Programming. In Knuth's concept, you define comments and use a tool called Web to help you generate code. My own approach doesn't expect to do that because I prefer my comments to be more abstract. I never got into Knuth's Web -- what I have was what I'd developed independently.

So my strategy is to first do a back-of-the-envelope sketch, followed by a Mind Map, if the project is complex enough. Then I rough out classes and fill them with comments and skeleton methods. If they are doing something gnarly, like string operations, at that point I'll start writing unit tests and the code to be tested. I start to build a git archive and take snapshots of important work/changes.

Now things begin to cycle around in a continuous process of refinement and enhancement as the project takes on more and more of its final shape. Eventually, the project becomes functionally complete, it goes into Beta and Management lays off the entire department I'm working in before it hits maintenance mode. After about the fourth time that happened I gave up on Corporate America in disgust and that's why I only do gig work these days.

[Liutauras Vilda]

Tim Holloway wrote:I would rather call TDD a design philosophy. JUnit is a framework, but hardly the only one for TDD.

Well, yes, I used (or rather misused) word framework figuratively here.

Tim Holloway wrote:So my strategy is to first do a back-of-the-envelope sketch, followed by a Mind Map, if the project is complex enough. Then I rough out classes and fill them with comments and skeleton methods.

In the corporates they more like to see diagrams drawn in a Miro or Lucidchart so called professional diagramming software accompanied with few POCs (Proof of Concept) done, but if you say it eventually results may result in the same, then I guess it is not the problem in tools here. P.S. I know your long lasting unconditional "love" for managers and anything related to that. ... and I always giggle reading your posts of this kind

[Tim Holloway]

I'm a sucker for for productivity tools and drawing templates (I have a whole drawer full.  Even got an IBM HIPO template).

I like FreeMind for mind-mapping, jGantt for Gantt Charting and ArgoUML for the rare UML stuff I do (mostly swim lane diagrams) , All off these are open-source Java apps.

I have no real problem with managers. Most I could tolerate and some were very good. Management, on the other hand...

One project I did, they took us all to lunch, congratulated us and said if the product didn't immediately make a ton of money, they'd dump it and can us all. And they did within 3 months. Hardly enough time to establish market share, I think, but it was a Macintosh product, the original owners had just sold the company and new management was PC-oriented, I think. They also believed in management-by-intimidation, which never works well with me.

That was also when I first encountered blatant age discrimination. I was in my late 30's.

[Tim Holloway]

I sneer at Dilbert apps. Today's "must-have" is tomorrow Rational Rose. Overpriced, single-vendor, mainly designed to keep Dogbert employed.

And I'm usually the one charged with picking out tools, so I rarely have had to deal with that nonsense.

The one commercial-only product I do prefer is Visio, because you can attach properties to the graphic objects. There is no open-source equivalent, and my attempts to get people to help me create one failed. I have the exact opposite of charisma. So I make do with graphviz. At least I can place its directives into Java Autodocs, generate a graph and incorporate it into the finished Autodocs. People don't realize just how powerful autodocs (and their equivalents, such as doxygen) can be.

While I never got into Rational, I understand that Oracle built a set of documentation standards based on Rational's principles and I once worked for a former Oracle person, who pushed it on us.

So for a typical project from me, you'll get:

ES - Executive Summary. 1-2 page justification for project and possible solutions.
FS - Functional Specification. Guide to the general internal design and operation of the product.
IS - Implementation Specification. Guide to the technical innards of the product.
SAG -  System Administrator's guide.
OG - System Operator's Guide
UAM - User Administrator's Manual
UM - User's manual


Details vary. Generally you'll get the ES and FS and possible IS. OG is not uncommon. the others (and possibly more) as needed. All document are based on a common Word (actually LibreOffice) template for consistency.