4

I have a bitbucket repo which uses bitbucket-pipelines to deploy to a local repository on azure (for our development server). I am working on the build step that the pipelines will use before it deploys to azure. The only thing my build step does right now is output built files into a given directory which is gitignored. It then force adds the gitignored build folder. It then amends to the commit that triggered the pipeline, and finally force pushes the commit to master.

So my file looks something like this

# bitbucket decided to make the repository shallow this line
# makes the repo unshallow so we can push later
- git fetch  https://<bitbucket-repo> --unshallow
# doing some setup so we can run the build scripts
- npm install
- npm install -g gulp
# just building files for now we can add tests in later
- npm run build:single
# forcing the build files to be included in the commit
# so that azure has access to the files.
- git add --force public/build/ 
# do some git configuration so it will let us commit
- git config --global user.email $GIT_USER_EMAIL
- git config --global user.name "\$GIT_USER_NAME"
# add to the last commit so we can keep its message
# this is so we can see the last commit message that was
# done on azure without creating a new commit message
# this command edits the previous commit and should
# never be done when that commit has already been 
# pushed to your target branch and if your target branch is
# public.
- git commit --amend --no-edit
# the below line pushes to a branch on azure we setup as a local branch
- git push --force https://<azure-branch-repo> master

My question is:

Am I going to break anything with this git workflow? And are there any suggestions that you have?

I'm figuring that only my pipelines script will push to azure's local repo so it's okay to amend the commit which would otherwise probably be a bad idea if someone else pushes to it. Is this something I should be concerned about? I would like to keep the original commit message as azure displays it in the list of previous deploys. If they all have deploy names correlated with their bitbucket commits it makes it much simpler to go back to a certain deployment.

I was also wondering if this was an okay time to use git push --force as I hear the --force flag is considered dangerous. Since I am committing the build files to git for each deployment I will have a commit that strays away from the repo with all the build files in it. My thought was using --force would forget the last stray commit and just have everything the way bitbucket-pipelines built it. I'm not sure if my interpretation of --force push is correct.

John
  • 7,114
  • 2
  • 37
  • 57
  • Have you considered a dedicated deployment repository? I.e.: a repository that keeps only your build artifacts? That would feel a lot cleaner for me, and you could still deploy using git. (For instance, see https://stackoverflow.com/q/23774002/4715679 for more info.) OK, you would have to manually extract the last source repo’s commit message using `git log` to be able to re-use that message for the deployment (artifact) repo, but that’s not difficult. – BlueM Jun 14 '17 at 06:03
  • @BlueM sorry, I'm unfamiliar with deployment repositories. I will have to read up on them, would that still allow me to automate the build? Where would I put the build step? – John Jun 14 '17 at 06:10
  • @BlueM you should note that this is for my development servers. It's set up to be automated so it's less hassle during development, but during deployment to production we copy files over manually. – John Jun 14 '17 at 06:14
  • If your build script is the only one pushing to the target repo, then `--force` isn't as dangerous as it normally is. That being said, it's still IMHO bad practice to do it routinely, especially when it's completely unnecessary. First as someone else suggested, if you want to version control your build artifacts, do it in their own repository. If you don't want to do that, for whatever reason, then just check them into this repository in their own commit, rather than altering whatever commit happens to be at the branch tip. – jingx Jun 19 '17 at 20:41
  • @jingx I think I do want to version control my build artifacts, and the main reason I think that would be because my azure deployment needs the built files. Now my question is can I deploy to this new build repo from the main repo without having the same exact problem as above. – John Jun 19 '17 at 20:48

1 Answers1

6

you should note that this is for my development servers. It's set up to be automated so it's less hassle during development, but during deployment to production we copy files over manually

Even so, Git is not made for deployment or storing build artifact which can be generated.
What I proposed in "Separate development and deployment git repositories" is to publish your artifacts (the binaries in the build folder) to an artifact repository.

It doesn't have to be Nexus: see "Build and Deploy your Java app to an Azure web app", which uses FTP (taken from the Azure web app essentials page on the Azure portail).

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • So could I just upload the files via ftp from bitbucket pipelines what would be the advantage of doing it from azure the way your guide shows? – John Jun 19 '17 at 23:11
  • I'm following this guide now which was linked through the guide you gave. https://www.visualstudio.com/en-us/docs/build/apps/node/nodejs-to-azure I feel I'm getting a lot closer to a proper solution. I'll keep you updated on what happens and if I get this nailed down, but I'll likely award you the bounty once I've got it figured out or if the bounty period is close to running out, but it should award it to you when the bounty period runs out since I accepted your answer. – John Jun 19 '17 at 23:39
  • Thanks by the way for your help so far. It was rather hard for me to find the proper documentation for the job when I didn't know what I was supposed to be searching for. – John Jun 19 '17 at 23:40
  • 1
    @John Yes, the idea is to not to have to rely on Git for binary publication (as opposed to source code management) – VonC Jun 20 '17 at 05:32