Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>When you talk about scaling CI you're really talking about scaling the use of your CI server to handle all your feature branches along with your mainline. Initially this looks like a good approach as the developers in a branch get all the advantages of the automated testing that the CI jobs include. However, you run into problems managing the CI server jobs (like you have discovered) and more importantly, you aren't really doing CI. Yes, you are using a CI server, but you aren't continuously integrating the code from all of your developers.</p> <p>Performing real CI means that all of your developers are committing regularly to the mainline. Easy to say, but the hard part is doing it without breaking your application. I highly recommend you look at <a href="http://continuousdelivery.com/" rel="noreferrer">Continuous Delivery</a>, especially the <em>Keeping Your Application Releasable</em> section in <em>Chapter 13: Managing Components and Dependencies</em>. The main points are:</p> <blockquote> <ul> <li>Hide new functionality until it's finished (A.K.A <a href="http://martinfowler.com/bliki/FeatureToggle.html" rel="noreferrer">Feature Toggles</a>).</li> <li>Make all changes incrementally as a series of small changes, each of which is releasable.</li> <li>Use branch by abstraction to make large-scale changes to the codebase.</li> <li>Use components to decouple parts of your application that change at different rates.</li> </ul> </blockquote> <p>They are pretty self explanatory except branch by abstraction. This is just a fancy term for:</p> <blockquote> <ol> <li>Create an abstraction over the part of the system that you need to change. </li> <li>Refactor the rest of the system to use the abstraction layer.</li> <li>Create a new implementation, which is not part of the production code path until complete.</li> <li>Update your abstraction layer to delegate to your new implementation.</li> <li>Remove the old implementation.</li> <li>Remove the abstraction layer if it is no longer appropriate.</li> </ol> </blockquote> <p>The following paragraph from the <em>Branches, Streams, and Continuous Integration</em> section in <em>Chapter 14: Advanced Version Control</em> summarises the impacts.</p> <blockquote> <p>The incremental approach certainly requires more discipline and care - and indeed more creativity - than creating a branch and diving gung-ho into re-architecting and developing new functionality. But it significantly reduces the risk of your changes breaking the application, and will save your and your team a great deal of time merging, fixing breakages, and getting your application into a deployable state. </p> </blockquote> <p>It takes quite a mind shift to give up feature branches and you will always get resistance. In my experience this resistance is based on developers not feeling safe committing code the the mainline and this is a reasonable concern. This in turn usually stems from a lack of knowledge, confidence or experience with the techniques listed above and possibly with the lack of confidence with your automated tests. The former can be solved with training and developer support. The latter is a far more difficult problem to deal with, however branching doesn't provide any extra real safety, it just defers the problem until the developers feel confident enough with their code. </p>
    singulars
    1. This table or related slice is empty.
    1. POHandling multiple branches in continuous integration
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USndyer
    1. USTom Howard
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POHandling multiple branches in continuous integration
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COTom, this only works well if 1) both the release and update are comparatively easy 2) most of your changes are well isolated. This is true for web dev, but if you're doing boxed product releases then stable versions have to remain stable at all costs, cause hotfixes are really expensive or even impossible in a large corporate environment.
      singulars
      1. PO
      1. USJevgeni Kabanov
    2. COreal CI isn't only about integrating, it is also about the feedback
      singulars
      1. PO
      1. USAnton Arhipov
    3. COI chose this as the answer (at least gave the bounty, please let me know if I somehow still need to mark it correct) but I think this is not a solution for my problem. I've written a followup at http://www.zeroturnaround.com/blog/continuous-integration-and-feature-branches/
      singulars
      1. PO
      1. UStoomasr
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload