Hey. To be honest I think that if your process takes more the 30 days to take you from SIT to PROD it is broken... Nothing should take that long, you should revise your practises imho
Thanks Dev for the quick response. I'll talk to the management. What is your thought about DEV to SIT, since we are developing a new project, it is taking way beyond 30 days for moving the service from Dev to SIT.
Initially I was planning to setup one single pipeline/workflow per service. That workflow move service from Dev-->QA-->SIT-->PROD. So once I start the workflow,based on approvals from the corresponding teams we can move the service from one environment to another. What would be your suggestion to handle this scenario ?
Let me reframe my question. With in GitHub Actions Workflow, is there a way to trigger a specific job manually, so that I can have 3 jobs to deploy on DEV, SIT and PROD. Then when ever SIT or PROD is ready to deploy with manual approval, I can trigger that job with in that Workflow.
You can't manually start a job in a workflow, but you can start a workflow. And while there is a way to do that (you can use a workflow_dispatch trigger which allows you to manually start a job), I would not recommend having different workflows for this purpose.
I think we need to go back to the "30 days" problem.
While it may make sense having a 30-day period to go from the first commit in dev to the service being in production, you wouldn't use the same workflow run.
The way I see it is:
1) a dev commits to Dev
2) CI starts
3) Not yet time to go to SIT, nothing to do... approval is NOT given, job can be cancelled or let time out
4) a dev commits to Dev
5) CI starts
6) Not yet time to go to SIT, nothing to do... approval is NOT given, job can be cancelled or let time out
[.....}
55) a dec ommits to DEv
56) CI start
57) build is good enough for SIT
58) approval is given
59) deploy to SIT
60) test
61) Test fails, approval is NOT given, job can be cancelled or let time out
[...]
95) a dec ommits to DEv
96) CI start
97) build is good enough for SIT
98) approval is given
99) deploy to SIT
100) test
101) test is succesfull, build is good for prod
102) approval is given
103) deplouy to prod
as you can see, there is no 30-day period between the steps. It may take 30 days or more to go all the way from the first commit to the deploy in prod, but the workflow run is not the same...
One workflow run starts at point 1 and "dies" at point 3
Another run starts at point 4 and "dies" at point 6
and so on so forth
The last one, which in fact goes all the way from dev to prod, starts at point 95 and completes to prod on point 103... that is hardly 30 days of work :)
Hey. To be honest I think that if your process takes more the 30 days to take you from SIT to PROD it is broken... Nothing should take that long, you should revise your practises imho
Thanks Dev for the quick response. I'll talk to the management. What is your thought about DEV to SIT, since we are developing a new project, it is taking way beyond 30 days for moving the service from Dev to SIT.
Initially I was planning to setup one single pipeline/workflow per service. That workflow move service from Dev-->QA-->SIT-->PROD. So once I start the workflow,based on approvals from the corresponding teams we can move the service from one environment to another. What would be your suggestion to handle this scenario ?
Let me reframe my question. With in GitHub Actions Workflow, is there a way to trigger a specific job manually, so that I can have 3 jobs to deploy on DEV, SIT and PROD. Then when ever SIT or PROD is ready to deploy with manual approval, I can trigger that job with in that Workflow.
You can't manually start a job in a workflow, but you can start a workflow. And while there is a way to do that (you can use a
workflow_dispatchtrigger which allows you to manually start a job), I would not recommend having different workflows for this purpose.I think we need to go back to the "30 days" problem.
While it may make sense having a 30-day period to go from the first commit in dev to the service being in production, you wouldn't use the same workflow run.
The way I see it is:
1) a dev commits to Dev
2) CI starts
3) Not yet time to go to SIT, nothing to do... approval is NOT given, job can be cancelled or let time out
4) a dev commits to Dev
5) CI starts
6) Not yet time to go to SIT, nothing to do... approval is NOT given, job can be cancelled or let time out
[.....}
55) a dec ommits to DEv
56) CI start
57) build is good enough for SIT
58) approval is given
59) deploy to SIT
60) test
61) Test fails, approval is NOT given, job can be cancelled or let time out
[...]
95) a dec ommits to DEv
96) CI start
97) build is good enough for SIT
98) approval is given
99) deploy to SIT
100) test
101) test is succesfull, build is good for prod
102) approval is given
103) deplouy to prod
as you can see, there is no 30-day period between the steps. It may take 30 days or more to go all the way from the first commit to the deploy in prod, but the workflow run is not the same...
(sorry for the super long comment haha)
Thanks Dev. Really appreciated your response. I get it how you are approaching the deployment process. Let me start thinking in that direction.