Geek Answers Handbook

Create Server Best Practices

I heard that Google has such an automatic process:

  • When you register, your code is checked at a temporary location.
  • It is built.
  • Style checks are performed.
  • Tests are performed.
  • If there are no problems, the code goes to the real repository.
  • You receive an email containing test results, performance graphs, style test results, and whether your code is being verified.

So, if you want to know that you broke something or that you expected a big gain in performance, you simply registered and received an email with the message that you need to know.

What are your best practices for the build server?

+4
source share
3 answers

What you described for google is what every basic build process does. Specific projects may have additional needs, for example, how we deploy web applications from production to production:

  • Build start
  • The live site is disabled (Apache redirects to another directory where the Under Construction page is located).
  • SVN update starts for production server
  • Database Schema Deltas Launch
  • Tests run with updated source code and schema.
  • In the event of a failure, rollback is performed (SVN reverse and UNDO database schema)
  • The site is returning online
  • End ends
+5
source

On the java platform, I tried using every major CI system. My advice is that paying for a commercially supported solution was the cheapest build system I have ever seen. These things take time to support, support and troubleshoot. Especially with a heavy load on assemblies that work all the time.

+1
source

The example workflow that you give is similar to the one proposed by TeamCity . The idea was as follows:

  • code
  • Check for "pre-test"
  • Server CI tests "pre-commit"
  • If (and only if) tests pass, the CI server commits a code change to the main repo

This is a religious war, but I prefer:

  • Code - Test - Refactoring (cycle)
  • Fix
  • CI server also checks your commit

Each responsible programmer must complete all tests before committing.

The main argument for the first method is that it ensures that there is no broken code in SCM. However, I would say that:

  • You must trust your developers to verify before committing
  • If tests take a lot of time, the problem is your slow tests , not your workflow.
  • Developers aim to run tests quickly
  • Leaning on a CI server to run tests, you get a false sense of security
+1
source

More articles:


All Articles