Closed. This question is not about programming or software development. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed last month.
Improve this question
Any big project is subject of code freeze in special moments of the year, mine included. In our context, we work with microservices architecture, where each team is responsable for the entire cycle coding->deploying, where deployment means changing a k8s deployment.yaml file that points to a new docker image with the latest changes.
However, the way we deal with freezes is that we simply don't merge any changes into the deployment.yaml of any of our services, this way, k8s won't deploy anything new. But IMO this approach is not ideal and easily bypassed because there isn't any real blocker, it's just a common agreement that we won't merge such PRs so that we don't change the deployment.yaml.
This way, my question would be if there is a known way, be that in kubernetes configurations or somewhere else, where I can enforce a real freeze and be 100% sure that nothing will be deployed in the meantime?
Even better if I were allowed to keep merging changes in deployment.yaml of my services, but only have the changes actually deployed upon freezing end.
-> In case you also don't know any existing way to do it, please leave your suggestions on how you think this could be done because Im heading to my final project in college and I think this could be an interesting topic...
The answer to this question will vary according to some parameters, but there are generally 2 main access points that can change production which should be controlled in order to achieve a hermetic code freeze -
CI/CD pipelines - This is the most common way to deploy changes to production these days. In my previous company, when we wanted to prevent developers from deploying changes during a code freeze, we would delete production credentials from the CI/CD system during the code freeze, and that way no change can be deployed even if it is merged to master.
As #larsks mentioned in the comments - if you are using GitOps, you might have to pin the current change to a specific commit/tag in git.
Manual changes - If developers in the organization have access to change production manually, you will have to address this as well. You can either block manual access until the end of the code freeze, or make sure the policy is clearly communicated to everyone with production access (since manual changes don't are less probable to happen unintentionally)
Another point to address when implementing code freeze is out of band access to apply hotfixes and other urgent changes. When cutting access to production there should still be an emergency route allowing changes to production to be applied, and it should be simple and quick - because it will often be applied in times of stress and downtime.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I ask because my team previously was trying to "do" scrum. We had 2-week sprints, but no releases to go with those sprints! There were several other reasons for this, but one big one was that deployments took too long and were too complicated to do that frequently.
You sort of answered your own question: if deployments take too long, they can't be done frequently and you can't have short iterations, you can't ship the code at anytime, you can't demo progresses at the end of an iteration, etc. So, in your context, not having an automatic deployments was a major impediment that should have been identified and removed very early (through inspection and adaptation).
Back to the question now. Is automatic deployment a crucial practice? Well, as hinted, I'd say it depends on the context: a project with a simple and straightforward manual deployment process can probably live with it. Is automatic deployment a good practice? I think so: an automated process is typically faster, less error prone and humans obviously don't add much value at doing something that can be automated (see also Three Strikes And You Automate).
I'd say yes, it's an essential practice. If deployments are too complicated and taking too long you've got a bigger problem. I think you should sort that out. You have to do them sometime. Doing the work to make it possible to build at will can only help your project.
Being able to claim the "agile" label isn't important; having an automated, hands-off, repeatable build is the point.
Crucial, no, you can get away without it but, as you've found out, everything that you have to do manually will slow down your cycle time.
You should be aiming to automate as much as possible, build, deployment, regression testing and so forth, so that you're not unnecessarily delayed.
The idea of a sprint without a release is an ... interesting ... one. I can't say I've ever seen that tried before :-)
You have to distinguish clearly two things: a shippable product increment and an actual shipment. First is what your team should produce every sprint, second is what may happen with it if it makes business sense.
In other words: what the team produces each and every sprint must be a piece of completely working code, a new increment of whatever it is that you develop. It should be fully built and tested - which is why automatic testing and building environment is a must if you are to do this. However, whether it should be deployed every sprint to production servers and whether this should be automatic is a completely different thing which has nothing to do with the development process itself.
If it is a requirement that you deploy to live production server every sprint (by all means a very good thing to do) then it would probably make sense to automatize it, but whether this process is fully automatic or no shouldn't impede your team's ability to produce fully working code every sprint.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
when starting with a project and using source control i find it hard to separate the things people are working on so they don't either write duplicate code or think it should be named one thing and so on.
this problem diminishes over time because the general foundation is in place and it's easier to separate the tasks so they don't overlap as much
how do you manage working with source control in the beginning phase?
EDIT:
I can see that it don't really have anything to do with source control, but it gets more apparent when you have source control too. so the question becomes more along the lines of "how do you manage to separate the tasks so they don't overlap too much. I think it's really hard and i haven't really seen much about how to do it.
Well, as far as source control goes, somebody needs to take the lead and set up the basic structure of the project, directories, etc. and communicate it to the team. On projects I work on, this is usually an architect or senior developer, someone who knows the best practices for project organization for the team/company.
With respect to avoiding having multiple people working on the same tasks, that's a project management function; someone needs to determine what tasks need to be done, and communicate it to the team. If you are working in an agile/scrum environment, the team may divide and hand out work items amongst themselves, but in either case you need to communicate to avoid doing the same work twice.
EDIT
To address the issue of multiple people working on the same task, I tend to work on smaller teams, 2-6 people; in this environment, I have had a lot of success with a scrum-influenced approach using the Crystal Clear methodology:
Architect(s)/designer(s) come up with high level design
Architect(s)/designer(s) define iterations/deliveries, the first of which is a "project skeleton" which consists of architectural and back-end components and a thin slice of the app
Lead person breaks up features into 1-3 day tasks/units of work (estimated)
Team meets and discusses priority, timing and dependencies of tasks, and divides up the first set of tasks
The team has brief daily meetings to discuss status/priorities and dependencies, and change direction if necessary
With larger projects/teams, you will almost certainly need someone whose main job is dedicated to tracking status, dependencies and conflicts.
I don't think source control has much to do with the problem of coordinating people's efforts (except that it can catch some "conflicts" when people erroneously try to modify the same files in different ways -- but, that's not as good as preventing conflicts, and even just "preventing conflicts" does not per se ensure that everybody is working on what they should ideally be working right now, in terms of priorities). Coordination is properly managed with practices (and perhaps tools, e.g. Pivotal Tracker -- but, using the right practices is even more important than using nice tools!-) that specifically focus on ensuring coordination. For example, the practices that Tracker is designed to support and enhance, such as story-based iterative planning, and other compatible ones, such as stand-ups, offer ways to meet these needs.
You must be having a base version that everyone is using, check that into the repository, and then make incremental changes to the repository, make sure that everyone works on different part of the code, commit every working change, and resolve conflicts as and when they occur. That is how I would do it.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
I work as an in-house developer for a manufacturing company. We make software for the manufacturing process, not really control software, more like process flow.
We are using a Scrum process to develop the software, albeit tailored to fit with our team and environment, and this is working quite well. We're coming to the end of a sprint and the software is at a stage where the product owner wants to deploy it.
Previously, i.e. before Scrum, we would have deployed the software. Now I feel like we have developed the software, we've passed all the user-defined/agreed release tests and demonstrated the software to the PO with a simulator, we have achieved our goals. We are ready to provide deployment support but I don't think it should be our responsibilty to deploy.
What are other peoples experiences? Should the dev team do the deployment or should we just hand over the completed software to the PO and provide support?
Summing up
A lot of great responses, thanks. The question may seem like I'm trying to squirm out of work or responsibility, maybe I am a little ;o) What I'm more interested in is other peoples processes. The problem we face here is that if the dev team deploy the software then we end up providing 24/7 support to production for the software. No prob, except there are only two of us. So, to allow us to get back to developing software rather than providing support all the time I thought it might be helpful to get the "IT" team involved in development process. Hopefully this will get the 'buy-in' and then allow them to deploy and provide first level support. We also have a plant in Mexico and its difficult for the dev team to go and deploy there, it makes more sense for the local support to do it, with guidance/advice from the developers.
Just to let you know, the IT engineers did deploy the software, with guidance/advice from dev. Its gone quite well, the customer is happy - he's got increased value for his software, and isn't that what its all about?
I don't think Scrum as a methodology addresses deployment responsibility. I've worked for large organizations with a deployment team completely independent of the development team. I've also worked at small organizations where the development team handles deployment. Ideally, the deployment team is separate from development, but it would almost never be the PO (which I assume means product owner). The PO usually signs off, but is not usually the best choice for handling deployment.
Who gets the call at 3am when the software isn't working or a system died? If it's the dev team then by all means expect to own the deployment (since you own production).
Best practice for organizations that can support is to provide the Operations group with deployment instructions and good wishes. Bottles of scotch help too.
If your production controls are lax, than tighten them up. A book like "Visible Ops" is a great guide to getting things under appropriate levels of control in the appropriate hands.
I'm a dev mgr with responsibility over multiple products. I have my dev teams produce builds of deployment artifacts, such as .war files, that can be simply deployed to Tomcat web server using it's manager interface or web service API. The configuration for the app is all set and self-contained within the .war file. Hence it is straightforward for the person doing deployment to just take it and "drop it in", so to speak.
If we don't get this level of ease of deployment to where deployment can be completely decoupled from the development team, then I view that as a failure on the dev team's part to adequately do their job.
The person doing deployment proceeds to release a given product to numerous customer sites - that's not a productive activity for me to let developers be doing - they have products to design and create as that is their specialization expertise.
In our organization the deployment responsibility also overlaps with the first tier production support responsibility.
We practice some scrum methodology but I've never viewed this issue as tied to software development process methodology, per se.
the software process is not completed until the working software is in the hands of the users that need it - otherwise it's just "shelfware"
if there is no one else to be responsible for deployment and configuration management, then you're it ;-)
I would think as an "In-house" developer it would be your responsiblity (unless there is a specialised deployment team) to deploy the new software whereas if you were from an external company then it would be upto them to deploy it themselves, unless specified in the contract.
Depends on the project and what "deployment" means for you. Since I am a web developer, deploying mostly .NET applications with an Sql Server database, I always prefer the deployment be done by a release manager or deployment manager. Why? Because separation of jobs ensures that problems are caught when they need to be.
The developers job should be to provide the required objects or instructions on how to deploy, then someone else deploys to a staging environment. If something goes wrong during deployment to staging, the deployment instructions are corrected until the deployment to staging works flawlessly. That way, there will hopefully be no mistakes when the same deployment script is used to move the code to production. In other words, not only must you test your code but also the deployment script.
of course, in the real world, this doesn't always happen because of personnel issues, but this would be my ideal.
Seems fairly simple to me- if not you, then who? Would actual deployment responsibility have fallen to some other team before you started using Scrum? If not, then I don't see why Scrum would change that.
If the dev team was providing the deployment before scrum, they should continue to do so, unless Management has specifically said that someone else should do it. If managment hasn't said, then they haven't really thought about it, and just expected that it would happen magically, like it always has.
If you don't like that, bring it up with management, but do the work until told differently.
I think you have to man-up and deploy the software. unless you are working in an organization that has some kind of serious data security issues and or SOX issues with allowing the unclean to deal with the production end of things.
I agree with the first comment - SCRUM has nothing to do with it. In fact I would think it's far better for you to be deploying as you'll know first hand how well things are working and be right there to get feedback from those users.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
What is continuous integration and what are its benefits?
This is by far the best explanation I have read so far.
At its simplest, it is simply a mechanism that rebuilds your project whenever a check in is made into some revision control system (CVS etc). This can be extended though to include running tests, all the way through to generating a CD image, mounting it within VMs, installing the product and running full tests on it.
It has the simple advantage of highlighting when code changes break the system as early as possible. Not only does it detect breaks in the code, it highlights who caused the break. This psychological effect is very effective in encouraging good testing prior to check in!
It is the practice of ensuring that all aspects of your software development process are lined up to permit the daily creation of a working version of your product. It is best known as part of Extreme Programming.
This involves things as far afield as build automation, automated testing, daily check-ins, using a source code repository, etc. But the ultimate goal is to help the entire project run according to core Agile Principles so that you deliver early and often. This, in turn, helps you leverage feedback from your users, etc.
+1 for the link to Fowler's page.
Personally, I just found it "nice" to know whenever something didn't compile because we had the poor practice of having a single build (yes, we developed on the production build; we were awesome). We hadn't got the integrated testing phase before I left.
After a while, it did, however, lessen the amount of massive coding changes (compared to the "check in and pray my changes don't conflict" that was rampant). Eventually, most developers started making small changes frequently just to get confirmation from the CC.Net tray icon.
Overall, I found it very comforting to know that we could send out a build immediately if we had to. Had we had just a few smoke tests integrated, I think the stress-level would have been substantially lower.
Just to refresh. At this point there is a huge difference between Continuous Integration (CI) and Continuous Delivery (CD). While most of posts above described CD I'll try to show how CI extends now CD definition. Having all the tools needed to build a package and deploy new version of app automatically is a crucial part of CD. Adding to that test automation (based on three level verification: General Health-check, Detailed Statistics and Historical entries) and a proper governance you're creating a really good piece of CI. Only because of such an extended definition building extraordinary cloud tools is possible. Think about muleESB or esbeetle.com. For both of them CI is something natural although only the second one is supporting both ESB and ETL components.
I hope that it was helpful.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 days ago.
Improve this question
In an ideal world, our development processes would be perfect, resulting in regular releases that were so thoroughly tested that it would never be necessary to "hotfix" a running application.
But, unfortunately, we live in the real world, and sometimes bugs slip past us and don't rear their ugly heads until we're already busy coding away at the next release. And the bug needs to be fixed Now. Not as a part of the next scheduled release. Not tonight when the traffic dies down. Now.
How do you deal with this need? It really can run counter to good design practices, like refactoring your code into nice, discrete class libraries.
Hand-editing markup and stored procedures on a production server can be a recipe for disaster, but it can also avert disaster.
What are some good strategies for application design and deployment techniques to find a balance between maintenance needs and good coding practices?
[Even though we test a lot before we release, ] What we do is this:
Our SVN looks like this:
/repo/trunk/
/repo/tags/1.1
/repo/tags/1.2
/repo/tags/1.3
Now whenever we release, we create a tag which we eventually check out in production. Before we do production, we do staging which is [less servers but] pretty much the same as production.
Reasons to create a "tag" include that some of the settings of our app in production code are slightly different (e.g. no errors are emailed, but logged) from "trunk" anyway, so it makes sense to create the tag and commit those changes. And then checkout on the production cluster.
Now whenever we need to hotfix an issue, we fix it in tags/x first and then we svn update from the tag and are good. Sometimes we go through staging, with some issues (e.g. minor/trivial fixes like spelling) we by-pass staging.
The only thing to remember is to apply all patches from tags/x to trunk.
If you have more than one server, Capistrano (link to capify.org doesn't go to the intended anymore) is extremely helpful to run all those operations.
One strategy is to heavily use declarative-style external configuration files for the different components.
Examples of this:
Database access/object-relational mapping via a tool like IBatis/IBatis.NET
Logging via a tool like JLog/NLog
Dependency injection via a tool like Spring/Spring.NET
In this way, you can often keep key components separated into discrete parts, hotfix a running application without recompile, and seamlessly use source control (particularly in comparison to stored procedures, which usually require manual effort to source control).
We divide our code in framework code and business customizations. Business customization classes are loaded using a separate classloader and we have tool to submit changes to a running instance of production. whenever we need a change in any class we change it and submit it to a running instance. the running instance will reject the old classloader and use a new classloader insance to load the classes again. This is similar to Jboss hot deploy of EJBs.