The value of an auto increment column is set back to zero when you are having an empty table and restarting the MySQL DBMS.
We run into this issue by using the auto increment value as a history id into a second table.
How can you work around this issue?
The easiest way is to order by id descending on the second table or to setup a "start up" shell script that calculates and sets the auto increment value.
The following lines are loud thoughts so far. I will give it a try and implement a fitting module for that. But so far, it is really just an idea.
You started your zend framework 2 translation by using the official translation guide for zend framework 2 and it was running fine with some words.
But then, you started working agile, using git flow and doing this by using multiple branches. It turned out that you will get a lot of merge conflicts (also on git) with your translation files if something had changed on your develop branch and on your feature branch. This results in high maintenance costs.
So what to do?
Here is my basic idea. Decouple the translation file from your code.
First of all, you want to shift from file based to database based translation.
After that, you reduce the usage of the database and add caching
Shift from file based to database based translation
Create a database with the name like "translation"
Inside this database, create a table called "keys" with the columns "id", "key_name" (or "name") and "created_at"
Inside this database, create as many "language" tables as you want
Each "language" table has the following columns "id", "key_id", "key_value" (or "value") and "created_at"
After that, create a basic import that inserts all names in the table "keys" and all values in the fitting "language" table
Next, you have to create an "translation adminstration" frontend to maintain the existing "translation keys" with its fitting "translation values" according to the right language.
continuous delivery (each commit moves system into stable and releaseable version)
development and operation is merged together to create a infinie loop of release and feedback (both directions)
share knowledge and experience
Define clearly what is a release (new feature, bugfix, and so one).
Again DevOps is not a new layer between the two areas.
Responsibilites is still clear to reproduce scenarios (automate as much).
It is about people, not about tools. Implement culture of communication.
Try to find conceptual deficits (also software design problems) as early as possible.
Add a version number to your database layout (most likly same release number than code) - flyway, liquibase, self-made
The Area Matrix
area 1 - extend development to operations
use tools like puppet/chef/cfengine to provision environments from versioned code
fast feedback through automations
reuse of code and tools
reliability of delivery process and provisioning
area 2 - extend operations to development
provide monitoring and log files to development (or automated database snapshots to reproduce bug on development machine)
share information about state in production
enable development to improve
enable development to trace production incidents
area 3 - embed development into operations (end user experience is goal to reach)
set stability and capacity as development goals
align goals, share incentives
area 4 - embed operations into development
operations gives feedback about the design of the application that is under development, early and often
avoid not releaseable design
Recipes And Pitfalls
automate to ensure repeatability and foster collaboration (build once on a build server and release)
consider kanban (scrum is more for development but bad for organisation)
consider thorough change and config management - content management
track to ensure traceability (which build/release contains which tickets/bugs - artifactory)
monitor to support accountability (nagios and everything)
dashboard what you are doing (talk to each other what you are doing or what you have done)
use version control to ensure reproducibility (no manual tweaking after checkout)
consider pipelines/process from "put in feature/bugfix to release"
create (executable) documentation to, well, document (try to define goals and what it needs to reach it)
align goals and incentives of devs and ops (small cycle time)
ask and help, open culture of communication
respect your colleagues (stability against features, both leads to great user experience)