|
At work our C embedded devices code (Microchip) and C# based server stack is historically in Subversion source control. Everything gets built from CruiseControl.Net. Newer stuff is just switching over to Java. That's stored in a private GIT repository and continuous build in Jenkins. Developers use their own builds locally at the dev and unit test phase, automated build for anything system test and beyond. Each team has their own server or two managing this, and regularly re-configure for new branches beyond trunk. Docs and issues managed from Confluence and JIRA. No automated deploy for us. We're not that advanced! We do have some Selenium scripts defined to do automated testing of UI. Decairn fucked around with this message at 20:39 on Feb 1, 2015 |
#
¿
Feb 1, 2015 20:37
|
|
|
|
| # ¿ Apr 29, 2024 00:07 |
|
|
Space Whale posted:What I mean is after you coalesce your feature branches into dev, and you're ready to deploy, sometimes that dev branch doesn't merge smoothly into master. So, why not just overwrite master with it? Go back a couple of posts - because master is "what works". It is also what everyone also understands is reliable (production ready or in production) without asking whether it works or not. If dev doesn't merge smoothly into master you've likely broken some unit tests or regression and need to reassess what should be the reference to move on with. You cannot move on until that is resolved. Also, you can have continuous integration on master that you set and forget until it complains after a bad merge, there's less maintenance to do.
|
|
#
¿
Feb 10, 2015 02:38
|
|