In semantic-release it's possible to specify a branch. For this, the documentation only states:
The branch on which releases should happen.
What effect has this property? What happens if I do not use it? What happens if I use it, and run semantic-release on the specified branch, respectively, what happens if I run it on a different branch?
This option defines the branch from which semantic-release will make releases.
If you don't set it it will automatically set to the default: master.
When semantic-release runs, if the CI job has been triggered on this branch (due to a commit being merged or pushed) it will make a release. IF the CI job was triggered on a different branch, semantic-release will do nothing and log that nothing has to be done as the current branch is not the release branch.
Related
I am new to Git. For my project, I have a branch called staging which is a branch off of master. I created a new branch called salesforce_update off of the staging branch. When I am on the staging branch, everything runs and renders well. When I switch over to the salesforce_update branch, it runs fine but when it renders, all of the styling on the page is gone. The data on the page displays correctly and functionality still works. Is there a reason why this is happening?
If you are using a task runner to compile your assets you may run into issues when switching branches with it running. Make sure to restart your task runner after switching.
I have started to use Git package inside RStudio . It seems to work fine for Master branch. But adding another branch, you can commit any changes through the GUI but the "push" button doesn't work. Any thoughts how this can be fixed? I can do the push through the terminal but not GUI.
As per Hadley's explanation:
If you try to synchronise this [new] branch to GitHub from inside RStudio,
you’ll notice that push and pull are disabled. To enable them,
you’ll need to first tell Git that your local branch has a remote
equivalent:
git push --set-upstream origin <branch-name> After you’ve done that
once, you can use the pull and push buttons as usual.
Flyway is a very nice tool to automate database updates (also called migrations). However, as of version 1.7 it relies on a completely linear sequence of migrations. This assumption is immediately void if you have a production system for which you have to deliver fixes while you are already developing new stuff. The FAQ argues correctly that this is a non-issue for the production system itself, but if you have development and/or QA-systems that already on the development branch, you need to run migrations from the fixes for the production version out of band.
A solution that would allow this is pending with Issue 138, but is not done yet. Since this is pretty much a deadly problem: are there any clever workarounds if I want to use it right now?
The approach I recommend (and which becomes almost essential in a Continuous Delivery/deployment) environment is using Feature Toggles and release from HEAD, instead of using Feature or Release branches. This is then combined with backward compatible migrations to complete alleviate this problem.
If for some reason that isn't an option for you, you don't have to wait very much longer.
Flyway 1.8 (which will include the fix for 138) will be out soon.
The problem is obsolete since Flyway version 2.0: if you set the outOfOrder flag then flyway will also execute migrations with earlier version numbers that have not been applied yet. You need however to make sure that such out of band migrations can be applied in any order to the later migrations, or you will run into serious trouble.
With Flyway-1.7 you could make the following workaround. If you have a development and a production branch, you could have separate instances of flyway including separate metadata tables (say, SCHEMA_HISTORY and SCHEMA_HISTORY_DEV) for the production and the development branch. On the production server there is only the SCHEMA_HISTORY and you work as usual; for the development server you have both, and each time you run flyway you first run it on the production branch sqls with the SCHEMA_HISTORY and then on the development branch sqls with the SCHEMA_HISTORY_DEV.
When you switch branches you have to merge the SCHEMA_HISTORY_DEV into SCHEMA_HISTORY. (You need to exclude the initial revision and reset the CURRENT_VERSION on SCHEMA_HISTORY.) And when flyway-1.8 comes out, you do this merge and throw SCHEMA_HISTORY_DEV away.
Net solution for a website, consisting of 5 projects, and there are a few(less than 10) developers working on the solution. We deploy almost on a daily basis.
The question is, how to setup the SVN repo to support this scenario (the daily deploy), also mentioning that not every commited file should go to production, there is a QA check before deploying.
Try out TeamCity
(CI tool) as its free for smaller amounts of CI. this may be better for you than CruiseControl.Net as CCNET is very configuration heavy as its all done via XML. TeamCity uses wizards to create the scripts to manage releases
if you need any other help on CI then let me know as its something I am evangelistic about.
What you want to do is commonly referred to as Continuous integration (CI).
While you can do that using Subversion, it is probably not the right tool for the job.
There is special CI software, which will allow you to easily automate the necessary tasks (checkout from version control, compiling / building, running automatic tests, deployment etc). An example would be CruiseControl.NET.
As to "not every commited file should go to production", the common solution is to have a special "release" branch, which gets deployed. Only tested code is merged there (or have the trunk always be stable, otherwise same model). Of course, you can also (better: additionally) have tests before your automatic deployment, and only deploy if all tests pass.
Working with a release branch
In practice, this means that people check in their code as they produce it. Sometimes this code will work, sometimes not. When the release time draws nearer, a "release branch" is created in Subversion. This release branch is then effectively a frozen snapshot of the source as it was at the time of branching. Now this branch can be used to compile & deploy the application, which can then be tested.
No new code is checked into the branch (but checkins can continue elsewhere). Only if a bug is detected in the branch, will there be a checkin into the branch to fix it. This continues until the branch passes all tests. Then the branch can be released as a new version of the software; afterwards the branch will only be used if the released version needs to be patched.
Of course, any bugfixes checked into the branch need to also be put into the trunk (either by merging branch -> trunk, for which Subversion provides special support, or by reimplementing the fix in the trunk, as appropriate).
When using an automated build system, it is usually a source control entry which executes tests (but I assume this can be configured to not be on every entry in a large team). How comes build applications have actions for source code checkins. Is there any need for this? So to summarise, is a build script executed by a source control entry or at a certain time everyday?
Also, the term "break the build" - does this mean code put source control and when the build is executed, it fails due to the code not passing a unit test/code coverage app returns negative results below a certain threshold?
Finally, what does a step mean? (Eg one step build)?
Thanks
So to summarize, is a build script executed by a source control entry or at a certain time everyday?
This depends. Some teams use a commit in the version control system as trigger, some teams use a temporal event as trigger (e.g. each hour). If you run the build after each change, you get immediate feedback. If you let some time run between two builds, you delay that feedback and, in case of a build failure, it's harder to identify the change(s) that are the cause. It may require more investigation.
Just to clarify the vocabulary, for me, "the build" is actually the script/tool that automates all the things that needs to be done (compiling, runing tests, etc). Then running this automated build continuously is what people call "continuous integration". And triggering a build on an event (time based or on commit), pulling the sources from the repository, running the build script, notifying people in case of failure is the responsibility of a "continuous integration engine".
Also, the term "break the build" - does this mean code put source control and when the build is executed, it fails due to the code not passing a unit test/code coverage app returns negative results below a certain threshold?
This is very binary indeed: the build passes, or it doesn't. When it doesn't, there can be many reasons: the code didn't compile, a test failed, a quality check failed (coding standards, code coverage, etc). If you commit some code than causes a build failure (whatever the reason is), then you "broke the build".
Finally, what does a step mean? (Eg one step build)?
In my opinion, a one step build means that you can build your entire application, run the tests, run the quality checks, produce reports, assemble the application, deploy it, etc with one command. This is a synonym of automated build (if you can't run your build in one step, i.e. if it requires human intervention, then it isn't fully automated).
Also, the term "break the build" -
does this mean code put source control
and when the build is executed, it
fails due to the code not passing a
unit test/code coverage app returns
negative results below a certain
threshold?
This could mean different things depending on company, project or team.
Usually "build" is some reference (usually automated) procedure which is either succeeds or not.
Thus "breaking the build" is doing something that leads failing of this reference procedure.
It could include or exclude unit-tests running, or regression test running, or deployment of your product, or whatever your team thinks should never fail.