Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
Use github flow or trunk based development.
Increase your CI checks to make you comfortable with merging/pushing to master multiple times a day.
All features should be behind feature flags, so they don't break everything else when pushed in an incomplete state.
Lastly when CI passes, build a single artifact and start the CD process. It's fine to have different deployment targets (staging, prod, etc) but you should push the same artifact to each whenever they pass the next vetting stage.
When CI fails, generate a report, ping the devs in slack, and fix it (reverting or patching). -
This flow seems tiresome compared to what my web dev team does.
Of course us web devs have the luxury of being able to deploy whenever and rollback whenever so this might be irrelevant for you as an app dev but here's how we do it:
* For a new feature we fork master, do a PR, deploy it to a separate test env (We have tons) Once approved it's merged to master.
* Master is auto deployed to our preprod-site and our staging-site (same code, but one uses apiData from prod and one uses apiData from staging apis)
* Before a release we do a bit of extra testing
Allthough I know this might not even be realistic for an app dev with scheduled release slots. I've worked for a govmt project with 1 release slot per quarter and then we had to have releasebranches that were frozen a week before the due date and tested for days. -
@Mmmyaa it IS being tested with other features, in the develop branch . and in the staging branch , it is being tested with cherry picked features.
can you explain how you can avoid cherry picking in a test branch? -
@jiraTicket yeah it isn't ideal for app dev. if i can ignore the naming of branches , you are basically saying that for a festure x, there is an individual testing in branch1-env1, followed by merging it alongside other features in branch2-env2/3 followed by a combined testing of branch2's code in env 2/3 , followed by a complete release from branch 2.
the problem of rolling back features from branch 2 will still exist . in webdev it may be easier to rollback, but in app dev, its somewhat easier to filter release tasks, cherry pick and roll forward. and github's intuitive ui prompts of "press to delete branch" that comes after merging is very tempting but nightmarish in this scenario -
@lungdart the problem here isn't automation, its the human nature and how to deal with it. how to add a check in ci-cd to only approve a pr if parallel team has done their task or if backend is ready or of qa has approved the code build?
-
> you are basically saying that for a festure x, there is an individual testing in branch1-env1, followed by merging it
Yes! When feature x has been tested in branch1-env1 and approved we can merge it to master and ship master to production. (I just take a glance at preprod before shipping)
Without other features being merged.
Cause normally we do features that are forks from master and are entirely stand-alone.
> alongside other features in branch2-env2/3 followed by a combined testing
Nope. In this case all features would be shippable on their own.
This is our common practice at least.
But that assumes being able to do that kinda thing. Currently we don't work with mega-features where a year of work has to be released at once. If I had to re-engineer a popular lib from v1 to v2 during a year of I wouldn't be able to do this, I'd have to have a long-running v2 fork.
is it necessary to have cherry picking a part of git branching/release process?
we have 3 branches : develop, release and master.
currently every dev works on feature as follows : they make a branch out of develop, write code, raise pr against develop, get it reviewed and merge back to develop. later the release feature list is generated, and we cherry pick all the release related commits to release branch, and make a prod build out of release branch. finally, the code is moved to master and rags are generated accordingly.
so the major issue with this process is feature blocking. as of now, i have identified 4 scenarios where a feature should not be released :
1. parallel team blocker : say i created a feature x for android that is supposed to go in release 1.2.1 . i got it merged to develop and it will be cherry picked to release on relase day. but on release day it is observed that feature x was not completed by the ios dev and therefore we cannot ship it for android alone.
2. backend blocker : same as above scenario, but instead of ios, this time its the backend which hasn't beem created for the feature x
3. qa blocker : when we create a feature and merge it to develop, we keep on giving builds from develop branch adter every few days. however it could be possible that qa are not able to test it all and on release day, will declare thaf these features cannot be tested and should not be moved to release
4. pm blocker: basically a pm will add all the tickets for sprint in the jira board. but which tickets should be released are decided at the very late days of sprint. so a lot of tasks get merged to develop which are not supposed to go.
so there's the problem. cherry picking is being a major part of release process and i am not liking it. we do squash and merges, so cherry picking is relatively easy, but it still feels a lot riskier.
for 1 and 2 , we sometimes do mute releases : put code in release but comment out all the activation code blocks . but if something is not qa tested or rejected by pm, we can't do a mute release.
what do you folks suggest?
question