Off topic, but I would be willing to help set up Bamboo to have an actual deploy pipeline for the dashboard. The current system of manually git pulling on production seems to cause a lot of friction that leads to infrequent prod pushes and difficult fixing small problems like this one.
Let’s keep a branch which we can use for active development and then periodically merge something to a branch which is always kept in a stable state…I brought the codebase into an inconsistent state when I was merging changes which changed small parts of the system and then had to make other changes…I vote the following:
- master will be the branch which we will deploy – rebase that onto production
- develop is the place where things can be broken and when fixed, we just need to remember to merge and/or rebase onto master.
- never ever ever ever commit development code to production
1 Like
to getting this automated via Bamboo. Dashboard needs to be highly reliable and should never be pushed without as much testing as we can reasonably manage. 
That’s why I think develop (which CAN be in a messy state for a short period) and then when it’s reasonably stable…move to master which bamboo then rebases over production. Just my $0.02 on this matter…i’m planning on having master in a deployable state soon! Hopefully not making things too complex – just a middle-ground approach.
bold-faced are the branch names so it’s easy to see at a glance.
For that it’s worth, when doing a git operation in a script task after a checkout in Bamboo, make sure to do
git remote set-url origin ${bamboo.planRepository.repositoryUrl}
There’s a non supported plugin to do that as well, but I didn’t have a nice experience with it.
Also, there are a few tasks to handle variables in Bamboo, to increase them and everything, but you can use the buildNumber instead if desired.
3 Likes
In your mind, what are the criteria for moving commits from develop to master? Does having develop mean code isn’t originally being written in feature branches?
Here’s the branch organization I usually prefer. All new code is written in feature branches. Each feature branch corresponds to a ticket.
Development Deployment
----------- ----------
|
|
master ======> production
^ |
| |
|<-feature |
| |
|<-feature |
| |
|<-feature |
|
The upside of this is that it forces every feature/ticket to be totally complete before it is merged with master, and thus master stays pretty stable. (if testing is good enough, master could be the deploy branch itself). The downside is that feature branches can inevitably become pretty huge. (I’m reminded of last summer when the ID Dashboard’s new datastore and models came in a single pull request!)
1 Like
This could work…I like it better…however things like GCI happens – which is why master is currently in a state of flux – hence develop would exist to allow for merging easily without mucking up master, as has already happened. What we could do is a branch like gci2015 and use that to merge things piecemeal, but the end result is the same as develop; which means that it’s going to or may be unstable for a period of time (which is hopefully short). The determining factor for moving from develop->master is VERY subjective.
Hi there… I’ve just checked the status of Dashboard, it is not changed.
We can’t just talk, somebody should move. Create a production branch and merge my ‘production’ branch here, which with fix, and deploy it.
Can somebody with proper privileges stand out? @michael @r0bby @elliott @ryan
I do not have privileges.
I created a branch, which is (as far as I know) what’s running live on the server right now. When we release the new one, I’ll rebase master over that branch, but that branch will ALWAYS be in a clean state and reflects what is running on the production server (or what will shortly be deployed to the production server).
It is called production and is branched from commit 00c223e. Currently, I cherrypicked two commits: 963b129 and 963b129 into that branch.
master is slowly returning to a stable state 
– I have some time on my hands and may tackle the sign up page myself. @plypy’s GSoC contributions are improving code quality and are being merged as I review them.
I created a tag v2.0.1 and production can be deployed safely. production is currently 2 commits ahead of what’s deployed (@plypy’s fixes).
In addition to this, all modules are stable and can be deployed as git submodules. None of those were touched. This includes the globalnavbar.If you want, I can cherrypick the commits from GSoc so that they can be deployed immediately (opinions on this @elliott, @michael?)
Can you clarify what permissions you need on the repository?
I don’t know what this means but am happy to help you get those privileges.
Oh, to deploy and add @plypy’s changes – he’s made modifications which I cherrypicked into the production branch. You could probably do it – but we really should set up CI to deploy the production branch if it detects a commit. Automation is best for this.
I would say yes to automatically deploy to the staging environment, but have a manual step to deploy to prod. @elliott set up something like this for modulus and I think we should try to replicate that.
The production branch is ready to deploy…it has 2 fix commits which I cherry-picked. Currently, @plypy is rewriting the views in jade - I’m happy about this. Hopefully, by the close of GSoC – we SHOULD be in a stable state. He’s done an amazing amount of work – and high quality too. If somebody wants to (or can) – do a pull of the production branch – it’s branched from what is running on the server currently…you might want to hard reset to 00c223e (git reset --hard 00c223e) so that there are not merge conflicts – @plypy made a change which will conflict with a patch @michael made switching the URL for OpenMRS Ask. We should deploy this ASAP.