Back to Basics: What is a good check-in process? [closed]_问答_开发者

Closed. This question needs to be more focused. It is not currently accepting answers.

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 2 months ago.

Improve this question

My team has been working, for the most part, on our own projects. I write the code, check it in to source control, and rarely does anyone else see it (except the end product). Everyone else follows the same basic flow.

The team is starting to grow开发者_运维知识库 as are the projects we work on. We will soon need to start coding together on projects. The new guy has been less than successful in his attempts to follow any check-in process, resulting in broken builds.

Some of us have been talking about documenting our process as a first step to ensuring we're all on the same page. This would be light reading, not necessarily detailed "click this, type this, now click that" kind of stuff. For example, our first process doc would be "How to check in your code".

In my mind, the process would be similiar to...

Before check-in, confirm your code builds AND executes locally.
Get latest.
Manually resolve any conflicts.
Make sure your stuff builds and executes locally using the latest bits retrieved in the above step.
Check-in

So, on to the question. What additonal steps are necessary for a good check-in process? Does it really make sense to do something like this? I tend to think so since assuming we all know what to do hasn't really worked out.

Thanks!

I would bet against any procedure which assume the users will follow it. Humans rarely do so. But there is an alternative which would encourage everyone to do just what you wanted (and more, as appropriate):
1. Setup a continuous integration server and configure it to compile your code and run it (the same code you expect your guys to 'execute locally').
2. Make it shameful to break the build. Doing so is culture-dependent; sometimes just sharing the statistics will do the trick, sometimes you need to email the direct manager of whoever broke the build, whatever.

With this procedure, if implemented correctly, everyone will just do what it takes (e.g. if not doing get-latest is risky, they'll learn to do it with time)is).

Another issue to consider is performing peer code-review, but this one really depends on the team size and culture to be work (even though it is always cost-effective, it hardly even work, per my experience).

Instead of adding process, why not talk the "new guy" and tell him what is expected. When it comes to commit checklists, they need to be flexible and make room for commonsense. I've been in situations where a four hour build + two hour automated testing was required to commit a string change. Don't let it get ridiculous.

There should be very few concrete rules regarding commits. I like these rules:

Don't commit broken code. It must compile and run as expected.
Be mindful when merging.

If a developer's commit breaks the build, shame on them. If the developer introduces merge-damage, shame on them. Having said that, I like to have in place a few tools to make sure things don't get out of hand.

SCM sends commit diffs immediately to the entire team once a commit occurs.
Continuous Integration builds immediately. In my experience, checking for changing every 15 minutes is not enough. Either trigger the CI build via a hook or check every 1-5 minutes for changes.
Make commit history easily accessible via a browser.

I also like to have each commit signed-off by another team member. Some SCM systems can help with this workflow.

I think the 5 steps you outlined are the minimum that you must do to ensure that the build is not broken.

You will probably want to also run any code verification (unit tests, style cop, fx cop, code formatting) as a final step. You may also want to do code review before commit, or commit to a staging area for review.

You might also want do a clean checkout and build/test afterwards, as this can catch local files which have not been added. This is probably going a step too far if you have a build server, as it will catch this.

Code Check-In Best Practices

Encourage daily code check-in/commit/push.
Do Small code check-in/commit/push rather than big code volumes.
Commit Single Purpose of Code Changes Once: Avoid dividing a single change into multiple Commits/Changesets to commit, pack them on one Commit/Changeset if possible. For example, committing three Changesets for one bug fixing is not a good practice. Committing your changes one time is extremely helpful for performing code review as it is easy to locate changes in one revision.
Don't Commit Multiple Purposes of Code Changes once: Avoid committing multiple changes into one single Commit/Changeset as this would be so hard to distinguish them later. If you pack many purposes of changes in one revision, you likely close your door to rollback each individual change. For example, you have fixed two bugs #1 and #2 and committed them by one Commit/Changeset. Later on, if there is a request to roll back the fixing of bug #1, then it would take time to handle this scenario.
Pull the latest commits, if any, before you commit/push code.
Be mindful when merging: Manually resolve conflicts if any, take help from peer team members if required. 6.1. If you are not able to resolve conflicts, stash your changes 6.2. Pull latest code 6.3. Apply your stashed changes
Make sure the solution/project builds and executes locally using the latest bits retrieved in the above step. Don't commit broken code. It must compile and run as expected.
Commit Changes: 8.1 Blank comment is not accepted: Never leave comment blank when committing your code. Write proper comments about what changes are for along with story/bug id.8.2. Push Commit to Origin.
Integrate Slack or MS Teams or Cliq or Email with Jenkins to automatically send build break messages from Jenkins pipeline. Post a message at the used communication channel of whoever broke the build.
Make it shameful to break the build. Doing so is culture-dependent; sometimes just sharing the statistics will do the trick, post a message at MS Teams or Cliq Channel of whoever broke the build.
Setup a continuous integration (CI) server and configure it to compile your code and run unit tests.