search

thelac / boxplot

Plotting your inbox.
0 stars 0 forks source link

Discuss continuous deployment options #74

Closed danielsuo closed 10 years ago

danielsuo commented 10 years ago

Our master branch on github is a bunch of commits ahead of our master branch on heroku. Should figure out how we want to roll up master to heroku.

yjkogan commented 10 years ago

Should branch off a different, primary shared development branch, say, "devel" or "development." Then, when we want to release, merge "devel" into "master" which auto-pushes to heroku :)

danielsuo commented 10 years ago

How does testing work? Want the push to master to be as seamless as possible to encourage the continuous deployment

On May 28, 2014, at 10:47 PM, Yonatan Kogan notifications@github.com wrote:

Should branch off a different, primary shared development branch, say, "devel" or "development." Then, when we want to release, merge "devel" into "master" which auto-pushes to heroku :)

— Reply to this email directly or view it on GitHub.

yjkogan commented 10 years ago

Tests are auto-run whenever merged into devel. Merge from devel into master should never happen unless tests passed in last build of devel.

danielsuo commented 10 years ago

And what do those tests look like?

I think the flow is straight forward, but not sure what guards we want to put in place.

On May 28, 2014, at 10:55 PM, Yonatan Kogan notifications@github.com wrote:

Tests are auto-run whenever merged into devel. Merge from devel into master should never happen unless tests passed in last build of devel.

— Reply to this email directly or view it on GitHub.

yjkogan commented 10 years ago

No clue. Unit tests using node-unit or mocha? How to make them run automatically also up in the air. Set up Jenkins?

allenjhyang commented 10 years ago

At Yipit we have unit, functional, and in some cases acceptance / integration tests...unit tests don't touch the database or make requests, functional tests can.

For very highly sensitive repos or modules, we have an 100% coverage requirement, but these are painful. On the other hand, you don't want something 'highly sensitive' to break when somebody decides to push and then leave for the night

On Wed, May 28, 2014 at 11:16 PM, Daniel Suo notifications@github.comwrote:

And what do those tests look like?

I think the flow is straight forward, but not sure what guards we want to put in place.

On May 28, 2014, at 10:55 PM, Yonatan Kogan notifications@github.com wrote:

Tests are auto-run whenever merged into devel. Merge from devel into master should never happen unless tests passed in last build of devel.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHubhttps://github.com/thelac/boxplot/issues/74#issuecomment-44490303 .

allenjhyang commented 10 years ago

(We switched from Jenkins to Travis for our CI. Not sure why / what the differences are)

On Wed, May 28, 2014 at 11:20 PM, Allen Yang allen@yipit.com wrote:

At Yipit we have unit, functional, and in some cases acceptance / integration tests...unit tests don't touch the database or make requests, functional tests can.

For very highly sensitive repos or modules, we have an 100% coverage requirement, but these are painful. On the other hand, you don't want something 'highly sensitive' to break when somebody decides to push and then leave for the night

On Wed, May 28, 2014 at 11:16 PM, Daniel Suo notifications@github.comwrote:

And what do those tests look like?

I think the flow is straight forward, but not sure what guards we want to put in place.

On May 28, 2014, at 10:55 PM, Yonatan Kogan notifications@github.com wrote:

Tests are auto-run whenever merged into devel. Merge from devel into master should never happen unless tests passed in last build of devel.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHubhttps://github.com/thelac/boxplot/issues/74#issuecomment-44490303 .

kevinakwok commented 10 years ago

I remember when Gabriel first joined yipit and testing became a thing at Yipit

On Wed, May 28, 2014 at 8:21 PM, Allen Yang notifications@github.comwrote:

(We switched from Jenkins to Travis for our CI. Not sure why / what the differences are)

On Wed, May 28, 2014 at 11:20 PM, Allen Yang allen@yipit.com wrote:

At Yipit we have unit, functional, and in some cases acceptance / integration tests...unit tests don't touch the database or make requests, functional tests can.

For very highly sensitive repos or modules, we have an 100% coverage requirement, but these are painful. On the other hand, you don't want something 'highly sensitive' to break when somebody decides to push and then leave for the night

On Wed, May 28, 2014 at 11:16 PM, Daniel Suo notifications@github.comwrote:

And what do those tests look like?

I think the flow is straight forward, but not sure what guards we want to put in place.

On May 28, 2014, at 10:55 PM, Yonatan Kogan notifications@github.com

wrote:

Tests are auto-run whenever merged into devel. Merge from devel into master should never happen unless tests passed in last build of devel.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub< https://github.com/thelac/boxplot/issues/74#issuecomment-44490303> .

— Reply to this email directly or view it on GitHubhttps://github.com/thelac/boxplot/issues/74#issuecomment-44490550 .

danielsuo commented 10 years ago

Less infrastructure and more conceptual? As in, what would we test for? Probably functional, but what functional stuff would we do that isn't trivial?

On May 28, 2014, at 11:55 PM, kevinakwok notifications@github.com wrote:

I remember when Gabriel first joined yipit and testing became a thing at Yipit

On Wed, May 28, 2014 at 8:21 PM, Allen Yang notifications@github.comwrote:

(We switched from Jenkins to Travis for our CI. Not sure why / what the differences are)

On Wed, May 28, 2014 at 11:20 PM, Allen Yang allen@yipit.com wrote:

At Yipit we have unit, functional, and in some cases acceptance / integration tests...unit tests don't touch the database or make requests, functional tests can.

For very highly sensitive repos or modules, we have an 100% coverage requirement, but these are painful. On the other hand, you don't want something 'highly sensitive' to break when somebody decides to push and then leave for the night

On Wed, May 28, 2014 at 11:16 PM, Daniel Suo notifications@github.comwrote:

And what do those tests look like?

I think the flow is straight forward, but not sure what guards we want to put in place.

On May 28, 2014, at 10:55 PM, Yonatan Kogan notifications@github.com

wrote:

Tests are auto-run whenever merged into devel. Merge from devel into master should never happen unless tests passed in last build of devel.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub< https://github.com/thelac/boxplot/issues/74#issuecomment-44490303> .

— Reply to this email directly or view it on GitHubhttps://github.com/thelac/boxplot/issues/74#issuecomment-44490550 .

— Reply to this email directly or view it on GitHub.

yjkogan commented 10 years ago

I'd actually vote for unit tests. We can probably cover almost any possible error with unit testing our helper functions / instance methods. Plus, it'll make the code more modular and readable! Yes, they're probably trivial tests for now but it's good practice :).

I can work on this. I've been wanting to explore "fuzzing" tests